On 10/15/20 8:46 AM, Borislav Petkov wrote:
From: Borislav Petkov
... instead of poking at the MSR. For that, move the accessor functions
to misc.c and add a sysfs-writing function too.
> There should be no functional changes resulting from this.
Signed-off-by: Borislav Petkov
Cc: Thomas
On Wed, Oct 14, 2020 at 6:33 PM Dave Airlie wrote:
>
> There are a bunch of conflicts but none of them seemed overly scary,
> and sfr has provided resolutions for them all. I've put a tree up with
> my merge results, so you can tell me I did it wrong here:
>
Add DDR/L3 bandwidth votes for the pro variant of SC7180 SoC, as it support
frequencies upto 2.5 GHz.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
Linus,
Updates for tracing and bootconfig:
- Add support for "bool" type in synthetic events
- Add per instance tracing for bootconfig
- Support perf-style return probe ("SYMBOL%return") in kprobes and uprobes
- Allow for kprobes to be enabled earlier in boot up
- Added tracepoint helper
[resent with the mailing lists in Cc]
The following changes since commit ba4f184e126b751d1bffad5897f263108befc780:
Linux 5.9-rc6 (2020-09-20 16:33:55 -0700)
are available in the Git repository at:
git://git.infradead.org/users/hch/configfs.git tags/configfs-5.10
for you to fetch changes
On Thu, Oct 15, 2020 at 7:50 AM Andy Shevchenko
wrote:
>
> On Wed, Oct 14, 2020 at 10:46:16PM -0300, Vitor Massaru Iha wrote:
> > This adds the conversion of the runtime tests of test_list_sort,
> > from `lib/test_list_sort.c` to KUnit tests.
>
> Please, provide better commit message. For
On 10/14/20 11:38 PM, Stephen Rothwell wrote:
Hi all,
On Mon, 12 Oct 2020 19:56:49 +1100 Stephen Rothwell
wrote:
Today's linux-next merge of the akpm-current tree got a conflict in:
lib/kunit/test.c
between commit:
45dcbb6f5ef7 ("kunit: test: add test plan to KUnit TAP format")
The pull request you sent on Thu, 15 Oct 2020 11:33:08 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-10-15
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/93b694d096cc10994c817730d4d50288f9ae3d66
Thank you!
--
Deet-doot-dot, I am a bot.
On Thu, Oct 15, 2020 at 05:43:33PM +0100, Matthew Wilcox wrote:
> On Thu, Oct 15, 2020 at 10:42:03AM +0100, Christoph Hellwig wrote:
> > > +static void iomap_read_page_end_io(struct bio_vec *bvec,
> > > + struct completion *done, bool error)
> >
> > I really don't like the parameters
Hi Vladimir,
sorry for the delay, getting answers to all you questions seems to be
challenging for me. Unfortunately it's about 1 year ago when I was originally
working on this particular problem and obviously I didn't understand the full
problem...
On Wednesday, 14 October 2020, 19:31:03
On Thu, Oct 15, 2020 at 2:47 PM Andy Shevchenko
wrote:
>
> On Wed, Oct 14, 2020 at 10:46:16PM -0300, Vitor Massaru Iha wrote:
> > This adds the conversion of the runtime tests of test_list_sort,
> > from `lib/test_list_sort.c` to KUnit tests.
>
> > rename lib/{test_list_sort.c =>
On 10/15/20 4:43 AM, Vitor Massaru Iha wrote:
Hi Stephen,
On Thu, Oct 15, 2020 at 2:31 AM Stephen Rothwell wrote:
Hi all,
After merging the kunit-next tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
lib/bitfield_kunit.c: In function 'test_bitfields_compile':
On Thu, 15 Oct 2020 19:46:35 +0200 Dmitry Vyukov wrote:
> On Thu, Oct 15, 2020 at 7:41 PM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:e688c3db bpf: Fix register equivalence tracking.
> > git tree: bpf-next
> > console output:
On Thu, Oct 15, 2020 at 10:26:18PM +0800, Hanjun Guo wrote:
> On 2020/10/15 3:12, Nicolas Saenz Julienne wrote:
> > From: Ard Biesheuvel
> >
> > We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
> > incorporating masters that can address less than 32 bits of DMA, in
> >
On Thu, 15 Oct 2020 11:02:08 -0700 Jakub Kicinski wrote:
> On Thu, 15 Oct 2020 19:46:35 +0200 Dmitry Vyukov wrote:
> > On Thu, Oct 15, 2020 at 7:41 PM syzbot
> > wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:e688c3db bpf: Fix register
On Mon, Aug 24, 2020 at 02:39:32PM +0530, Viresh Kumar wrote:
> From: Stephan Gerhold
>
> The OPP core manages various resources, e.g. clocks or interconnect paths.
> These resources are looked up when the OPP table is allocated once
> dev_pm_opp_get_opp_table() is called the first time (either
On Thu, Oct 15, 2020 at 10:48:56AM -0700, Randy Dunlap wrote:
> On 10/15/20 10:02 AM, Ioana Ciornei wrote:
> > On Thu, Oct 15, 2020 at 03:06:42PM +, Jose Abreu wrote:
> >> From: Randy Dunlap
> >> Date: Oct/15/2020, 15:45:57 (UTC+00:00)
> >>
> >>> On 10/15/20 12:28 AM, Stephen Rothwell wrote:
update the api of call_rcu()
Signed-off-by: Hui Su
---
Documentation/RCU/whatisRCU.rst | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst
index c7f147b8034f..aa7d5ed20da5 100644
---
Hi Shuah,
I already sent the patch:
https://patchwork.kernel.org/project/linux-kselftest/patch/20201015120851.229242-1-vi...@massaru.org
On Thu, Oct 15, 2020 at 3:01 PM Shuah Khan wrote:
>
> On 10/15/20 4:43 AM, Vitor Massaru Iha wrote:
> > Hi Stephen,
> >
> > On Thu, Oct 15, 2020 at 2:31 AM
> Full randconfig file is attached.
>
This build error still happens when (on today's linux-next 20201015)
CONFIG_BPF=y
# CONFIG_BPF_SYSCALL is not set
CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
CONFIG_USERMODE_DRIVER=y
CONFIG_BPF_PRELOAD=y
CONFIG_BPF_PRELOAD_UMD=m
--
~Randy
Reported-by: Randy Dunlap
Be clear about @ptr vs the variable that @ptr points to, and add some
more details as to why the special barrier_data() macro is required.
Signed-off-by: Arvind Sankar
---
include/linux/compiler.h | 33 ++---
1 file changed, 22 insertions(+), 11 deletions(-)
diff
Static analysis discovered that some code in vfio_fsl_mc_set_irq_trigger
is dead code. Fixed the code by changing the conditions order.
Fixes: cc0ee20bd969 ("vfio/fsl-mc: trigger an interrupt via eventfd")
Reported-by: Colin Ian King
Signed-off-by: Diana Craciun
---
The following changes since commit bbf5c979011a099af5dc76498918ed7df445635b:
Linux 5.9 (2020-10-11 14:15:50 -0700)
are available in the Git repository at:
https://github.com/micah-morton/linux.git tags/safesetid-5.10
for you to fetch changes up to 03ca0ec138927b16fab0dad7b869f42eb2849c94:
On 10/15/20 12:48 AM, Christoph Hellwig wrote:
> On Sun, Oct 11, 2020 at 05:53:37AM +1100, Stephen Rothwell wrote:
>> Hi Naresh,
>>
>> Just adding Christoph and Jim to cc]
>
> Well, a Cc doesn't help on its own. Can you send an actual bug
> report including the setup, warnings and error
The VBUS control (PWREN) and over-current pins of USB 3.0 DWC3
controllers are on Exynos5410 regular GPIOs. This is different than for
example on Exynos5422 where these are special ETC pins with proper reset
values (pulls, functions).
Therefore these pins should be configured to enable proper
On Odroid XU LDO12 and LDO15 supplies the power to USB 3.0 blocks but
the GPK GPIO pins are supplied by LDO7 (VDDQ_LCD). LDO7 also supplies
GPJ GPIO pins.
The Exynos pinctrl driver does not take any supplies, so to have entire
GPIO block always available, make the regulator always on.
Fixes:
On Thu, Oct 15, 2020 at 02:59:05PM -0300, Vitor Massaru Iha wrote:
> On Thu, Oct 15, 2020 at 2:47 PM Andy Shevchenko
> wrote:
> >
> > On Wed, Oct 14, 2020 at 10:46:16PM -0300, Vitor Massaru Iha wrote:
> > > This adds the conversion of the runtime tests of test_list_sort,
> > > from
On Odroid XU board the USB3-0 port is a microUSB and USB3-1 port is USB
type A (host). The roles were copied from Odroid XU3 (Exynos5422)
design which has it reversed.
Fixes: 8149afe4dbf9 ("ARM: dts: exynos: Add initial support for Odroid XU
board")
Cc:
Signed-off-by: Krzysztof Kozlowski
---
Hi Greg,
On 18/09/2020 15:35, Chris Clayton wrote:
> Mmm, gmail on android seems to have snuck some html into my reply, so here
> goes again...
>
> On 14/09/2020 16:58, Greg KH wrote:
>> On Sun, Sep 13, 2020 at 09:40:56AM +0100, Chris Clayton wrote:
>>> Hi Greg and Arnd,
>>>
>>> On 24/08/2020
The Odroid XU has external pull ups for USB 3.0 over-current pins, so
disable the internal one.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5410-odroidxu.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410-odroidxu.dts
.
>
> The patches are tagged here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
> rxrpc-next-20201015
Pulled, thanks!
Hi Jean
+ Baolu who is looking into this.
On Thu, Oct 15, 2020 at 11:00:27AM +0200, Jean-Philippe Brucker wrote:
> Add a parameter to iommu_sva_unbind_device() that tells the IOMMU driver
> whether the PRI queue needs flushing. When looking at the PCIe spec
> again I noticed that most of the
On Thu, Oct 15, 2020 at 09:21:21PM +0300, Andy Shevchenko wrote:
> On Thu, Oct 15, 2020 at 02:59:05PM -0300, Vitor Massaru Iha wrote:
> > On Thu, Oct 15, 2020 at 2:47 PM Andy Shevchenko
> > wrote:
> > >
> > > On Wed, Oct 14, 2020 at 10:46:16PM -0300, Vitor Massaru Iha wrote:
> > > > This adds the
On Wed, Sep 16, 2020 at 01:18:48PM -0400, Lyude Paul wrote:
> Since we're about to start adding support for Intel's magic HDR
> backlight interface over DPCD, we need to ensure we're properly
> programming this field so that Intel specific sink services are exposed.
> Otherwise, 0x300-0x3ff will
On Thu, Oct 15, 2020 at 11:13 AM Arvind Sankar wrote:
>
> Be clear about @ptr vs the variable that @ptr points to, and add some
> more details as to why the special barrier_data() macro is required.
>
> Signed-off-by: Arvind Sankar
Thanks for this distinct cleanup.
Acked-by: Nick Desaulniers
The pull request you sent on Thu, 15 Oct 2020 13:59:00 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
> tags/sound-5.10-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c48b75b7271db23c1b2d1204d6e8496d91f27711
Thank you!
--
Deet-doot-dot,
On Tue, Sep 29, 2020 at 10:03:47AM -0400, Ross Philipson wrote:
> On 9/25/20 3:18 PM, Arvind Sankar wrote:
[...]
> > You should see them if you do
> > readelf -r arch/x86/boot/compressed/vmlinux
> >
> > In terms of the code, things like:
> >
> > addl%ebx, (sl_gdt_desc + 2)(%ebx)
> >
The modem firmware memory requirements vary between 32M/140M on
no-lte/lte skus respectively, so fixup the modem memory region
to reflect the requirements.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sc7180-trogdor-lte-sku.dtsi | 4
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
On Thu, Oct 15, 2020 at 05:50:51PM +0200, Greg KH wrote:
> On Thu, Oct 15, 2020 at 07:40:12PM +0530, Anmol Karn wrote:
> > On Thu, Oct 15, 2020 at 07:12:25AM +0200, Greg KH wrote:
> > > On Thu, Oct 15, 2020 at 05:47:12AM +0530, Anmol Karn wrote:
> > > > In rose_send_frame(), when comparing two
On Wed, Sep 16, 2020 at 01:18:51PM -0400, Lyude Paul wrote:
> Since we're about to add support for a second type of backlight control
> interface over DP AUX (specifically, Intel's proprietary HDR backlight
> controls) let's rename all of the current backlight hooks we have for
> vesa to make it
Hi All,
> -Original Message-
> From: Michael Auchter
> Sent: Tuesday, October 6, 2020 3:21 PM
> To: Ben Levinsky
> Cc: Ed T. Mooring ; Stefano Stabellini
> ; Michal Simek ;
> devicet...@vger.kernel.org; mathieu.poir...@linaro.org; linux-
> remotep...@vger.kernel.org;
Linus,
please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching
for-linus
to receive livepatching update for 5.10.
=
- livepatching kselftest output fix from Miroslav Benes
=
Thanks.
On Wed, Sep 16, 2020 at 01:18:50PM -0400, Lyude Paul wrote:
> Currently, every different type of backlight hook that i915 supports is
> pretty straight forward - you have a backlight, probably through PWM
> (but maybe DPCD), with a single set of platform-specific hooks that are
> used for
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Thu, 15 Oct 2020 13:59:11 +0100 you wrote:
> Here are a couple of fixes that need to be applied on top of rxrpc patches
> in net-next:
>
> (1) Fix a bug in the connection bundle changes in the net-next tree.
>
>
> Yes, it's well hidden but it's there. If the profile is made custom, then
> the p-states can be selected and "custom" default enables C6 but not C3
> (there is a note saying that it's not recommended for that CPU). If I
> then switch it back to the normal profile, the c-states are not restored
>
Hi Jens,
On Thu, Sep 17, 2020 at 3:09 PM Geert Uytterhoeven
wrote:
> Before commit 9495b7e92f716ab2 ("driver core: platform: Initialize
> dma_parms for platform devices"), the R-Car SATA device didn't have DMA
> parameters. Hence the DMA boundary mask supplied by its driver was
> silently
-s031-20201015 (attached as .config)
compiler: xtensa-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-rc1-dirty
Hi Rafael,
Sorry in advance for the long writing. I hope it makes sense.
On Thursday 15 Oct 2020 at 17:56:56 (+0200), Rafael J. Wysocki wrote:
> On Tue, Oct 13, 2020 at 2:39 PM Ionela Voinescu
> wrote:
> >
> > Hi Rafael,
> >
> > On Tuesday 13 Oct 2020 at 13:53:37 (+0200), Rafael J. Wysocki
On 10/15/20 9:49 AM, Oleg Nesterov wrote:
> On 10/15, Jens Axboe wrote:
>>
>> Reviewed-by: Oleg Nesterov
>
> Yes, but ...
>
>> +static void task_work_notify_signal(struct task_struct *task)
>> +{
>> +#if defined(CONFIG_GENERIC_ENTRY) && defined(TIF_NOTIFY_SIGNAL)
>
> as long as
On Thu, Oct 15, 2020 at 10:51 AM Linus Torvalds
wrote:
>
> Thanks, looks good to me [..]
Uhhuh. I already pushed things out, but my clang build (which I don't
do between each merge) shows a problem:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:650:8:
warning:
On Thu, Oct 15, 2020 at 11:20:30AM +0200, Michal Hocko wrote:
> > > I do have a vague recollection that we have discussed a kill(2) based
> > > approach as well in the past. Essentially SIG_KILL_SYNC which would
> > > not only send the signal but it would start a teardown of resources
> > > owned
On Thu, Oct 15, 2020 at 8:58 AM Jerome Brunet wrote:
>
>
> On Thu 15 Oct 2020 at 15:46, Ionela Voinescu wrote:
>
> > Hi guys,
> >
> > On Wednesday 23 Sep 2020 at 14:39:16 (+0200), Jerome Brunet wrote:
> >> If the txdone is done by polling, it is possible for msg_submit() to start
> >> the timer
There is double acquisition of the pm_lock from mhi_driver_remove()
function. Remove the read_lock_bh/read_unlock_bh calls for pm_lock
taken during a call to mhi_device_put() as the lock is acquired
within the function already. This will help avoid a potential
kernel panic.
Fixes: 189ff97cca53
On Mon, Oct 12, 2020 at 02:04:00PM +0800, Yi Wang wrote:
> From: zhanglin
>
> Add max_num_devices to limit dynamic zram device creation to prevent
> potential OOM
>
> Signed-off-by: zhanglin
> Signed-off-by: Yi Wang
Acked-by: Minchan Kim
On Thu, Oct 15, 2020 at 09:01:07AM -0400, Miaohe Lin wrote:
> Rework the list_add code to make it more readable and simplicity.
>
> Signed-off-by: Miaohe Lin
Acked-by: Minchan Kim
Linus,
please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-linus
to receive HID subsystem queue for 5.10. Highlights:
=
- Lenovo X1 Tablet support improvements from Mikael Wikström
- "heartbeat" report fix for several Wacom devices from Jason Gerecke
- bounds
On Thu, 15 Oct 2020 13:22:26 +0100
Colin King wrote:
> From: Colin Ian King
>
> Currently the success path in function vfio_fsl_mc_reflck_attach is
> returning an uninitialized value in variable ret. Fix this by setting
> this to zero to indicate success.
>
> Addresses-Coverity:
Tweak the DDR/L3 bandwidth votes on the lite variant of the SC7180 SoC
since the gold cores only support frequencies upto 2.1 GHz.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sc7180-lite.dtsi | 14 ++
1 file changed, 14 insertions(+)
create mode 100644
On Thu, Oct 15, 2020 at 9:37 AM Jakub Kicinski wrote:
>
> On Wed, 14 Oct 2020 17:17:49 +0800 YueHaibing wrote:
> > IF CONFIG_BPFILTER_UMH is set, building fails:
> >
> > In file included from /usr/include/sys/socket.h:33:0,
> > from net/bpfilter/main.c:6:
> >
Linus,
please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial.git for-linus
to receive the latest advances in computer science from trivial queue for
5.10. Thanks.
Anatoly Pugachev (1):
selftests:
On Thu, 15 Oct 2020 11:53:08 -0700 Alexei Starovoitov wrote:
> On Thu, Oct 15, 2020 at 9:37 AM Jakub Kicinski wrote:
> > On Wed, 14 Oct 2020 17:17:49 +0800 YueHaibing wrote:
> > > IF CONFIG_BPFILTER_UMH is set, building fails:
> > >
> > > In file included from /usr/include/sys/socket.h:33:0,
>
From: Willem de Bruijn
Fix two stragglers in the comments of the below rename operation.
Fixes: adc5e8b58f48 ("kernfs: drop s_ prefix from kernfs_node members")
Signed-off-by: Willem de Bruijn
---
fs/kernfs/dir.c| 2 +-
include/linux/kernfs.h | 2 +-
2 files changed, 2 insertions(+),
sgl_alloc_order() can fail when 'length' is large on a memory
constrained system. When order > 0 it will potentially be
making several multi-page allocations with the later ones more
likely to fail than the earlier one. So it is important that
sgl_alloc_order() frees up any pages it has obtained
and include in UAPI headers instead of .
The reason is to avoid indirect include when using
some network headers: or others ->
-> .
This indirect include causes on MUSL redefinition of struct sysinfo when
included both and some of UAPI headers:
In file included from
Currently if report_error_detected() or report_mmio_enabled()
functions requests PCI_ERS_RESULT_NEED_RESET, current
pcie_do_recovery() implementation does not do the requested
explicit device reset, but instead just calls the
report_slot_reset() on all affected devices. Notifying about the
reset
Commit bdb5ac85777d ("PCI/ERR: Handle fatal error recovery")
merged fatal and non-fatal error recovery paths, and also made
recovery code depend on hotplug handler for "remove affected
device + rescan" support. But this change also complicated the
error recovery path and which in turn led to the
On Thu, Oct 15, 2020 at 06:58:48PM +0100, Christoph Hellwig wrote:
> On Thu, Oct 15, 2020 at 05:43:33PM +0100, Matthew Wilcox wrote:
> > I prefer assigning ctx conditionally to propagating the knowledge
> > that !rac means synchronous. I've gone with this:
>
> And I really hate these kinds of
On Thu, Oct 15, 2020 at 11:56 AM Jakub Kicinski wrote:
>
> On Thu, 15 Oct 2020 11:53:08 -0700 Alexei Starovoitov wrote:
> > On Thu, Oct 15, 2020 at 9:37 AM Jakub Kicinski wrote:
> > > On Wed, 14 Oct 2020 17:17:49 +0800 YueHaibing wrote:
> > > > IF CONFIG_BPFILTER_UMH is set, building fails:
> >
On Tue, Oct 13, 2020 at 12:50 PM Jakub Kicinski wrote:
>
> On Tue, 13 Oct 2020 18:59:28 +0300 Aleksandr Nogikh wrote:
> > On Mon, 12 Oct 2020 at 09:04, Dmitry Vyukov wrote:
> > >
> > > On Sat, Oct 10, 2020 at 5:14 PM Jakub Kicinski wrote:
> > > >
> > > > On Sat, 10 Oct 2020 09:54:57 +0200
On 10/2/20 9:50 PM, Jarkko Sakkinen wrote:
...
> You can tell if your CPU supports SGX by looking into /proc/cpuinfo:
>
> cat /proc/cpuinfo | grep sgx
This is only true *after* applying this series, right?
Hello:
This patch was applied to bpf/bpf-next.git (refs/heads/master):
On Mon, 12 Oct 2020 18:09:53 +0100 you wrote:
> If bpf_prog_inc_not_zero() fails for skb_parser, then bpf_prog_put() is
> called unconditionally on skb_verdict, even though it may be NULL. Fix
> and tidy up error path.
>
>
Commit 22652ba72453 ("rtc: stop validating rtc_time in .read_time") removed
the code but not the associated comment.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-r9701.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/rtc/rtc-r9701.c b/drivers/rtc/rtc-r9701.c
index
It doesn't make sense to set the RTC to a default value at probe time. Let
the core handle invalid date and time.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-r9701.c | 22 --
1 file changed, 22 deletions(-)
diff --git a/drivers/rtc/rtc-r9701.c
This allows further improvement of the driver.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-r9701.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-r9701.c b/drivers/rtc/rtc-r9701.c
index 183c5a0fe78c..9165c180b0e6 100644
---
tm_wday is never checked for validity and it is not read back in
r9701_get_datetime. Avoid setting it to stop tripping static checkers:
drivers/rtc/rtc-r9701.c:109 r9701_set_datetime()
error: undefined (user controlled) shift '1 << dt->tm_wday'
Reported-by: Dan Carpenter
Set range and remove the set_time check. This is a classic BCD RTC.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-r9701.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-r9701.c b/drivers/rtc/rtc-r9701.c
index 9165c180b0e6..7ceb968f0e44 100644
The RTC core already sets to zero the struct rtc_tie it passes to the
driver, avoid doing it a second time.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-r9701.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/rtc/rtc-r9701.c b/drivers/rtc/rtc-r9701.c
index
On Fri, 16 Oct 2020 at 04:42, Linus Torvalds
wrote:
>
> On Thu, Oct 15, 2020 at 10:51 AM Linus Torvalds
> wrote:
> >
> > Thanks, looks good to me [..]
>
> Uhhuh. I already pushed things out, but my clang build (which I don't
> do between each merge) shows a problem:
>
>
On Thu, Oct 15, 2020 at 2:20 AM Michal Hocko wrote:
>
> On Wed 14-10-20 09:57:20, Suren Baghdasaryan wrote:
> > On Wed, Oct 14, 2020 at 5:09 AM Michal Hocko wrote:
> [...]
> > > > > The need is similar to why oom-reaper was introduced - when a process
> > > > > is being killed to free memory we
On Thu, 15 Oct 2020 12:03:14 -0700 Alexei Starovoitov wrote:
> On Thu, Oct 15, 2020 at 11:56 AM Jakub Kicinski wrote:
> > How so? It's using in-tree headers instead of system ones.
> > Many samples seem to be doing the same thing.
>
> There is no such thing as "usr/include" in the kernel build
> Let's determine the target nid only once in case we have none specified -
> usually, we'll end up with node 0 either way.
>
> Cc: "Michael S. Tsirkin"
> Cc: Jason Wang
> Cc: Pankaj Gupta
> Signed-off-by: David Hildenbrand
> ---
> drivers/virtio/virtio_mem.c | 28 +++-
On Wed, Oct 14, 2020 at 09:15:47AM +0200, Krzysztof Kozlowski wrote:
> I hit this since few days as well. Although the bisect points to the
> merge, the issue looks like a result of mentioned commit 4d03e3cc5982
> ("fs: don't allow kernel reads and writes without iter ops").
>
> The
Hi David/Richard
When you have time, can you take a look at this change? Thanks
Min
-Original Message-
From: min.li...@renesas.com
Sent: August 7, 2020 11:58 AM
To: richardcoch...@gmail.com
Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; Min Li
Subject: [PATCH net 4/4]
Hi David/Richard
When you have time, can you take a look at this change? Thanks
Min
-Original Message-
From: min.li...@renesas.com
Sent: August 7, 2020 11:56 AM
To: richardcoch...@gmail.com
Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; Min Li
Subject: [PATCH net 1/4]
Hi David/Richard
When you have time, can you take a look at this change? Thanks
Min
-Original Message-
From: min.li...@renesas.com
Sent: August 7, 2020 11:58 AM
To: richardcoch...@gmail.com
Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; Min Li
Subject: [PATCH net 2/4]
Hi David/Richard
When you have time, can you take a look at this change? Thanks
Min
-Original Message-
From: min.li...@renesas.com
Sent: August 7, 2020 11:58 AM
To: richardcoch...@gmail.com
Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; Min Li
Subject: [PATCH net 3/4]
On Thu, Oct 15, 2020 at 11:43 AM Minchan Kim wrote:
>
> On Thu, Oct 15, 2020 at 11:20:30AM +0200, Michal Hocko wrote:
>
> > > > I do have a vague recollection that we have discussed a kill(2) based
> > > > approach as well in the past. Essentially SIG_KILL_SYNC which would
> > > > not only send
Good day,
On Wed, Oct 14, 2020 at 06:31:49PM +0200, Arnaud POULIQUEN wrote:
> Hi Mathieu,
>
> On 10/14/20 1:25 AM, Mathieu Poirier wrote:
> > Introduce __rpmsg{16|32|64} types along with byte order conversion
> > functions based on an rpmsg_device operation as a foundation to
> > make RPMSG
On 2020-10-15 18:18, Pavel Machek wrote:
Hi!
> > I'm getting build problems in 5.10-rc0 in config for n900. ARM board.
> >
> > CONFIG_SMP=y
> > CONFIG_SMP_ON_UP=y
On its own, this doesn't break anything with multi_v7_defconfig.
I sent config off-list. Let me know if it does not arrive or if
On Wed, Oct 14, 2020 at 07:04:32PM +0200, Arnaud POULIQUEN wrote:
>
>
> On 10/14/20 1:25 AM, Mathieu Poirier wrote:
> > Use rpmsg byte conversion functions in order for the RPMSG
> > headers and generic functions to be used by external entities.
> >
> > Signed-off-by: Mathieu Poirier
> > ---
>
On Thu, 2020-10-15 at 18:59 +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Add a Kconfig menu for Intel DPTF (Dynamic Platform and Thermal
> Framework), put both the existing participant drivers in it and set
> them to be built as modules by default.
>
> While at it, do a few
On Thu, 2020-10-15 at 18:58 +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Change the names of DPTF participant drivers to adhere to the
> sysfs file naming conventions (no spaces present in the name in
> particular).
>
> Fixes: 2ce6324eadb0 ("ACPI: DPTF: Add PCH FIVR participant
Hi Jacopo,
On 15/10/2020 19:27, Jacopo Mondi wrote:
> Adjust reverse channel amplitude according to the presence of
> the 'high-threshold" DTS property.
>
> If no high threshold compensation is required, start with a low
> amplitude (100mV) and increase it after the remote serializers
> have
Hi Jacopo,
On 15/10/2020 19:27, Jacopo Mondi wrote:
> Break out the reverse channel setup configuration procedure to its own
> function.
>
> This change prepares for configuring the reverse channel conditionally
> to the remote side high threshold configuration.
>
> No functional changes
Hi Linus,
Please pull the following Kselftest next update for Linux 5.10-rc1
This kselftest update for Linux 5.10-rc1 consists of enhancements to
-- speed up headers_install done during selftest build
-- add generic make nesting support
-- add support to select individual tests:
- Selftests
On Thu, Oct 15, 2020 at 12:26 PM Jakub Kicinski wrote:
>
> On Thu, 15 Oct 2020 12:03:14 -0700 Alexei Starovoitov wrote:
> > On Thu, Oct 15, 2020 at 11:56 AM Jakub Kicinski wrote:
> > > How so? It's using in-tree headers instead of system ones.
> > > Many samples seem to be doing the same thing.
Allow streaming from self picture path and main picture path at the same
time.
Take care for s_stream() callbacks to not be called twice.
When starting a stream, s_stream(true) shouldn't be called for the isp
and the sensor if the other stream is already enabled (since it was
already called).
On Thu, 15 Oct 2020 at 21:28, Kees Cook wrote:
>
> On Wed, Oct 14, 2020 at 09:15:47AM +0200, Krzysztof Kozlowski wrote:
> > I hit this since few days as well. Although the bisect points to the
> > merge, the issue looks like a result of mentioned commit 4d03e3cc5982
> > ("fs: don't allow kernel
Hi Jacopo,
On 15/10/2020 19:27, Jacopo Mondi wrote:
> Instrument the function that configures the reverse channel with a
> programmable amplitude value.
>
> This change serves to prepare to adjust the reverse channel amplitude
> depending on the remote end high-threshold configuration.
>
>
On Thu, Oct 15, 2020 at 09:00:13PM +0200, Petr Vorel wrote:
> and include in UAPI headers instead of .
>
> The reason is to avoid indirect include when using
> some network headers: or others ->
> -> .
>
> This indirect include causes on MUSL redefinition of struct sysinfo when
> included
601 - 700 of 922 matches
Mail list logo
