On 8/4/20 9:12 AM, Jürgen Groß wrote:
> On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
>> display frontend" from Apr 3, 2018, leads to the following static
>> checker warning:
>>
>> driver
On 2020-07-30 10:02, Xie He wrote:
Hi Martin,
I'm currently working on a plan to make all X.25 drivers (lapbether.c,
x25_asy.c, hdlc_x25.c) to set dev->hard_header_len /
dev->needed_headroom correctly. So that upper layers no longer need to
guess how much headroom a X.25 device needs with a co
Hi Nick,
On Thu, Jul 30, 2020 at 9:13 PM Nick Terrell wrote:
> From: Nick Terrell
>
> * Add support for a zstd compressed initramfs.
> * Add compression for compressing built-in initramfs with zstd.
>
> I have tested this patch by boot testing with buildroot and QEMU.
> Specifically, I booted th
On Mon, Aug 03, 2020 at 11:33:39PM -0700, Linus Torvalds wrote:
> On Mon, Aug 3, 2020 at 10:59 PM Guenter Roeck wrote:
> >
> > Tested-by: Guenter Roeck
>
> Thanks.
>
> Greg, I updated my internal commit with Guenter's tested-by and some
> more commentary (I had tried to break out that file enti
>From PD Spec:
The Sink Shall transition to Sink Standby before a positive or
negative voltage transition of VBUS. During Sink Standby
the Sink Shall reduce its power draw to pSnkStdby. This allows
the Source to manage the voltage transition as well as
supply sufficient operating current to the Sin
On Thu, Jul 30, 2020 at 9:11 PM Nick Terrell wrote:
>
> From: Nick Terrell
>
> Please pull from
>
> g...@github.com:terrelln/linux.git tags/v10-zstd
>
> to get these changes. Alternatively the patchset is included.
>
> Hi all,
>
> This patch set adds support for a ZSTD-compressed kernel, ramdis
On 03-08-20, 16:24, Ionela Voinescu wrote:
> Right, cpufreq_register_driver() should check that at least one of them
> is present
> (although currently cpufreq_register_driver() will return
> -EINVAL if .fast_switch() alone is present - something to be fixed).
I think it is fine as there is no gu
On Mon, Aug 03, 2020 at 05:36:07PM +0300, Dan Carpenter wrote:
> The devm_ioremap() function returns NULL on error, it doesn't return
> error pointers. This bug could lead to an Oops during probe.
>
> Fixes: f046e4a3f0b9 ("memory: jz4780_nemc: Only request IO memory the driver
> will use")
> Sig
MSM bus scaling has moved on to use interconnect framework
and downstream bus scaling apis are not present anymore.
Remove them as they are nop anyways in the current code,
no functional change.
Signed-off-by: Sai Prakash Ranjan
---
.../gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 24 ---
dri
From: Rajan Vaja
Use ZynqMP specific mux clock flags instead of using CCF flags.
Signed-off-by: Rajan Vaja
Signed-off-by: Tejas Patel
Signed-off-by: Amit Sunil Dhamne
---
drivers/clk/zynqmp/clk-mux-zynqmp.c | 22 +-
drivers/clk/zynqmp/clk-zynqmp.h | 8
2 fil
From: Rajan Vaja
Currently firmware passes CCF specific flags to ZynqMP clock driver.
So firmware needs to be updated if CCF flags are changed. The firmware
should have its own 'flag number space' that is distinct from the
common clk framework's 'flag number space'. So define and use ZynqMP
speci
Currently firmware is maintaining CCF specific flags and provides to
CCF as it is. But CCF flag numbers may change and that shouldn't mean
that the firmware needs to change. The firmware should have its own
'flag number space' that is distinct from the common clk framework's
'flag number space'. So
MSM bus scaling has moved on to use interconnect framework
and downstream bus scaling apis are not present anymore.
Remove them as they are nop anyways in the current code,
no functional change.
Signed-off-by: Sai Prakash Ranjan
---
.../gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c | 51
From: Rajan Vaja
Use ZynqMP specific divider clock flags instead of using CCF flags.
Signed-off-by: Rajan Vaja
Signed-off-by: Tejas Patel
Signed-off-by: Amit Sunil Dhamne
---
drivers/clk/zynqmp/clk-zynqmp.h | 9 +
drivers/clk/zynqmp/divider.c| 24 +++-
2 file
MSM bus scaling has moved on to use interconnect framework
and downstream bus scaling apis are not present anymore.
Remove them as they are nop anyways in the current code,
no functional change.
Sai Prakash Ranjan (2):
drm/msm/mdp4: Remove unused downstream bus scaling apis
drm/msm/mdp5: Remov
On Tue, Aug 04, 2020 at 08:12:10AM +0200, Marek Szyprowski wrote:
> exynos5_counters_get() might fail with -EPROBE_DEFER if the driver for
> devfreq event counter is not yet probed. Propagate that error value to
> the caller to ensure that the exynos5422-dmc driver will be probed again
> when devfr
On Mon, Aug 03, 2020 at 07:04:56PM -0300, Daniel Gutson wrote:
> > > > Think of this as an input device. You don't put the random input
> > > > attributes all in one place, you create a new device that represents the
> > > > input interface and register that.
>
> I'm having trouble with this. Wha
Ping?
On Monday, 27 July 2020, 13:12:18 CEST, Christian Eggers wrote:
> Storage technologies like FRAM have no "write pages", the whole chip can
> be written within one SPI transfer. For these chips, the page size can
> be set equal to the device size. Currently available devices are already
> big
On 04.08.20 08:35, Oleksandr Andrushchenko wrote:
On 8/4/20 9:12 AM, Jürgen Groß wrote:
On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following st
> > + if (vlan->proto == ETH_P_8021AD) {
> > + ocelot->enable_qinq = true;
> > + ocelot_port->qinq_mode = true;
> > + }
> ...
> > + if (vlan->proto == ETH_P_8021AD) {
> > + ocelot->enable_qinq = false;
> > + ocelot_port->qinq_mode = false
Convert the binding document for at25 EEPROMs from txt to yaml.
Signed-off-by: Christian Eggers
---
On Tuesday, 4 August 2020, 00:12:06 CEST, Rob Herring wrote:
> On Sun, Aug 02, 2020 at 07:46:26PM +0200, Christian Eggers wrote:
> > As there is virtually an infinite list of possible vendors and p
On Mon, Aug 3, 2020 at 10:59 PM Guenter Roeck wrote:
>
> Tested-by: Guenter Roeck
Thanks.
Greg, I updated my internal commit with Guenter's tested-by and some
more commentary (I had tried to break out that file entirely, it gets
ugly).
So it's now commit c0842fbc1b18 ("random32: move the pseud
Suggest kvmalloc, kvfree instead of opencoded patterns.
Signed-off-by: Denis Efremov
---
Changes in v2:
- binary operator cmp added
- NULL comparisions simplified
- "T x" case added to !patch mode
Changes in v3:
- kvfree rules added
scripts/coccinelle/api/kvmalloc.cocci | 188 ++
Hi, Linus,
On Mon, 2020-08-03 at 20:26 -0700, Linus Torvalds wrote:
> On Mon, Aug 3, 2020 at 2:44 PM Daniel Lezcano <
> daniel.lezc...@linaro.org> wrote:
> >
> >
ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/thermal/linux.git
> > tags/thermal-v5.9-rc1
>
> This was all rebased just an
On 30-07-20, 12:29, Dietmar Eggemann wrote:
> On 30/07/2020 06:24, Viresh Kumar wrote:
> > On 22-07-20, 10:37, Ionela Voinescu wrote:
> >> +++ b/drivers/base/arch_topology.c
> >> @@ -27,6 +27,7 @@ __weak bool arch_freq_counters_available(struct cpumask
> >> *cpus)
> >> }
> >> DEFINE_PER_CPU(unsi
On 03-08-20, 14:58, Ionela Voinescu wrote:
> Hi Viresh,
>
> On Thursday 30 Jul 2020 at 09:43:34 (+0530), Viresh Kumar wrote:
> > On 22-07-20, 10:37, Ionela Voinescu wrote:
> > > While the move of the invariance setter calls (arch_set_freq_scale())
> > > from cpufreq drivers to cpufreq core maintai
在 2020/8/4 上午6:49, Alexander Duyck 写道:
>> Cc: linux...@kvack.org
> I am assuming this is only separate from patch 18 because of the fact
> that it is from Hugh and not yourself. Otherwise I would recommend
> folding this into patch 18.
Yes, that's resaon for this patch keeps.
>
> Reviewed-by:
在 2020/8/4 上午6:45, Alexander Duyck 写道:
> Just to correct a typo, I meant patch 17, not 18. in the comment below.
>
>
> On Mon, Aug 3, 2020 at 3:42 PM Alexander Duyck
> wrote:
>>
>> On Sat, Jul 25, 2020 at 6:00 AM Alex Shi wrote:
>>>
>>> Now pgdat.lru_lock was replaced by lruvec lock. It's no
> From: Andy Shevchenko
> Sent: Wednesday, July 29, 2020 3:32 PM
> To: Yuan, Perry
> Cc: Sebastian Reichel; Matthew Garrett; Pali Rohár; Darren Hart; Andy
> Shevchenko; Limonciello, Mario; Linux PM; Linux Kernel Mailing List; Platform
> Driver
> Subject: Re: [PATCH] platform/x86:dell-laptop:Add ba
On Sat 01 Aug 08:55 PDT 2020, Amit Pundir wrote:
> Add initial dts support for Xiaomi Poco F1 (Beryllium).
>
> This initial support is based on upstream Dragonboard 845c
> (sdm845) device. With this dts, Beryllium boots AOSP up to
> ADB shell over USB-C.
>
> Supported functionality includes UFS,
Hi Mark,
>> currently THREAD_SIZE is always in power of 2, which will waste
>> memory in cases there is need to increase of stack size.
>
>If you are seeing issues with the current stack size, can you please
>explain that in more detail? Where are you seeing problems? Which
>configuration options
在 2020/8/3 下午11:07, Michal Hocko 写道:
> On Thu 30-07-20 10:16:13, Alex Shi wrote:
>>
>>
>> 在 2020/7/30 上午2:06, Hugh Dickins 写道:
>>> On Wed, 29 Jul 2020, Alex Shi wrote:
Is there any comments or suggestion for this patchset?
Any hints will be very appreciated.
>>>
>>> Alex: it is no
在 2020/8/3 上午2:20, Alexander Duyck 写道:
> Feel free to fold it into your patches if you want.
>
> I think Hugh was the one that had submitted a patch that addressed it,
> and it looks like you folded that into your v17 set. It was probably
> what he had identified which was the additional LRU ch
On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This is the sync up with the canonical definition of the
display protocol in Xen.
1. Add protocol version as an integer
Version string, which is in fact an integer, is hard to handle in the
code that supports diff
exynos5_counters_get() might fail with -EPROBE_DEFER if the driver for
devfreq event counter is not yet probed. Propagate that error value to
the caller to ensure that the exynos5422-dmc driver will be probed again
when devfreq event contuner is available.
This fixes boot hang if both exynos5422-d
On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following static
checker warning:
drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_ge
On Mon, Aug 03, 2020 at 10:58:55PM -0700, Guenter Roeck wrote:
> On Mon, Aug 03, 2020 at 08:12:51PM -0700, Linus Torvalds wrote:
> > On Mon, Aug 3, 2020 at 8:01 PM Guenter Roeck wrote:
> > >
> > > The bisect log below applies to both the sparc and the powerpc build
> > > failures.
> >
> > Does th
On 03/08/2020 20.29, Kees Cook wrote:
> Hi,
>
> I wonder if we should explicitly saturate the output of the overflow
> helpers as a side-effect of overflow detection?
Please no.
(That way the output
> is never available with a "bad" value, if the caller fails to check the
> result or forgets th
On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
It is possible that the scatter-gather table during dmabuf import has
non-zero offset of the data, but user-space doesn't expect that.
Fix this by failing the import, so user-space doesn't access wrong data.
Fixes:
From: Wanpeng Li
Return 0 when getting the tscdeadline timer if the lapic is hw disabled
Suggested-by: Paolo Bonzini
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/lapic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index cfb8504
From: Wanpeng Li
Check apic_lvtt_tscdeadline() mode directly instead of apic_lvtt_oneshot()
and apic_lvtt_period() to guarantee the timer is in tsc-deadline mode when
wrmsr MSR_IA32_TSCDEADLINE.
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/lapic.c | 4 ++--
1 file changed, 2 insertions(+), 2 del
On Sun 02 Aug 04:15 PDT 2020, Tianjia Zhang wrote:
> On an error exit path, a negative error code should be returned
> instead of a positive return value.
>
> Fixes: adaafaa393ef1 ("phy: qcom-ufs: add support for QUALCOMM Technologies
> UFS PHY drivers")
> Cc: Yaniv Gardi
> Signed-off-by: Tianj
On Mon, Aug 03, 2020 at 06:09:56PM +0200, Nicolas Saenz Julienne wrote:
> + if (IS_ENABLED(CONFIG_ZONE_DMA) && (gfp & GFP_DMA))
> + return end <= DMA_BIT_MASK(zone_dma_bits);
> + if (IS_ENABLED(CONFIG_ZONE_DMA32) && (gfp & GFP_DMA32))
> + return end <= DMA_BIT_MASK(3
On Mon, Aug 03, 2020 at 04:59:23PM -0400, Michael S. Tsirkin wrote:
> Since this is a modern-only device,
> tag config space fields as having little endian-ness.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> include/uapi/linux/virtio_input.h | 18 +-
> 1 file changed, 9 insertion
On 8/3/20 4:11 PM, Daniel Vetter wrote:
> I did a few greps for main console data structures, and there's a few
> places outside of drivers/video/console:
> - a braille driver
> - a sisusbvga driver
> - fbcon, but I think that's fine if we leave that officially under
> fbdev maintainership
> -
> From: Matthew Garrett
> Sent: Tuesday, August 4, 2020 1:54 PM
> To: Yuan, Perry
> Cc: kernel test robot; s...@kernel.org; p...@kernel.org; dvh...@infradead.org;
> a...@infradead.org; Limonciello, Mario; kbuild-...@lists.01.org; linux-
> p...@vger.kernel.org; linux-kernel@vger.kernel.org; platfor
04.08.2020 04:41, YueHaibing пишет:
> If CONFIG_PM is not set, gcc warns:
>
> drivers/staging/media/tegra-vde/vde.c:916:12:
> warning: 'tegra_vde_runtime_suspend' defined but not used [-Wunused-function]
>
> Make it __maybe_unused to fix this.
>
> Signed-off-by: YueHaibing
> ---
> v2: both sus
03.08.2020 18:42, Sowjanya Komatineni пишет:
> This patch adds support to capture from the external sensor
> based on device graph in the device tree.
>
> Driver walks through the device graph to create media links
> between the entities and registers and unregisters video devices
> when the corre
On Mon, Aug 03, 2020 at 08:12:51PM -0700, Linus Torvalds wrote:
> On Mon, Aug 3, 2020 at 8:01 PM Guenter Roeck wrote:
> >
> > The bisect log below applies to both the sparc and the powerpc build
> > failures.
>
> Does the attached fix it?
>
> Linus
> From 780c8591bce09bbdd2908b
On 11.07.20 00:34, Stefano Stabellini wrote:
Hi all,
This series is a collection of fixes to get Linux running on the RPi4 as
dom0. Conceptually there are only two significant changes:
- make sure not to call virt_to_page on vmalloc virt addresses (patch
#1)
- use phys_to_dma and dma_to_phys
On Tue, Aug 04, 2020 at 05:46:30AM +, Yuan, Perry wrote:
> It is not patch issue, the kernel config needs to add "CONFIG_ACPI_BATTERY=y"
In that case you probably want to add a dependency to ACPI_BATTERY in
the DELL_LAPTOP Kconfig.
--
Matthew Garrett | mj...@srcf.ucam.org
syzbot has bisected this issue to:
commit 4ffcd582301bd020b1f9d00c55473af305ec19b5
Author: Michael Chan
Date: Mon Sep 19 07:58:07 2016 +
bnxt_en: Pad TX packets below 52 bytes.
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=167b0f0490
start commit: ac3a0c84 Merge g
The performance modules in BlueField are present in several hardware
blocks and each block provides access to these stats either through
counters that can be programmed to monitor supported events or
through memory-mapped registers that hold the relevant information.
The hardware blocks that includ
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 09a0bd07764359650d41dbcb723f81321e523217
commit: 00d9990acb23c4319a1dc961d4e29a9213923b67 mailbox: pcc: make
pcc_mbox_driver static
date: 9 weeks ago
config: x86_64-randconfig-c002-20200803 (attached as
On Mon, Aug 03, 2020 at 03:13:49PM -0700, David Miller wrote:
> From: YueHaibing
> Date: Fri, 31 Jul 2020 14:49:52 +0800
>
> > If CONFIG_INET_XFRM_TUNNEL is set but CONFIG_IPV6 is n,
> >
> > net/ipv4/ip_vti.c:493:27: warning: 'vti_ipip6_handler' defined but not used
> > [-Wunused-variable]
> >
g.h: No
> such file or directory
>28 | #include
> | ^~
>
> Caused by commit
>
> bba6f4f52c31 ("rpmsg: move common structures and defines to headers")
>
> I have used the vhost tree from next-20200803 for today.
Yes, I
On 03-08-20, 22:31, Dongdong Yang wrote:
> From: Dongdong Yang
>
> This patch provides USF(User Sensitive Feedback factor) auxiliary
> cpufreq governor to support high level layer sysfs inodes setting
> for utils adjustment purpose from the identified scenario on portable
> equipment. Because the
> From: kernel test robot
> Sent: Saturday, August 1, 2020 1:08 PM
> To: Yuan, Perry; s...@kernel.org; mj...@srcf.ucam.org; p...@kernel.org;
> dvh...@infradead.org; a...@infradead.org; Limonciello, Mario
> Cc: kbuild-...@lists.01.org; linux...@vger.kernel.org; linux-
> ker...@vger.kernel.org; plat
When devm_clk_get() returns -EPROBE_DEFER, i.MX6 PCI driver should
NOT print error message, just return -EPROBE_DEFER is enough.
Signed-off-by: Anson Huang
---
drivers/pci/controller/dwc/pci-imx6.c | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git
On Thu, Jul 30, 2020 at 06:01:20PM +0300, Kirill Tkhai wrote:
> On 30.07.2020 17:34, Eric W. Biederman wrote:
> > Kirill Tkhai writes:
> >
> >> Currently, there is no a way to list or iterate all or subset of namespaces
> >> in the system. Some namespaces are exposed in /proc/[pid]/ns/ directorie
Hi Crt,
I love your patch! Yet something to improve:
[auto build test ERROR on iio/togreg]
[also build test ERROR on v5.8 next-20200803]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
h
From: kernel test robot
drivers/mailbox/pcc.c:575:3-8: No need to set .owner here. The core will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Fixes: 00d9990acb23 ("mailbox: pcc: make pcc_mbox_driver st
On Thu, Jul 30, 2020 at 07:47:14PM +0900, Tetsuo Handa wrote:
> syzbot is reporting OOB read bug in vc_do_resize() [1] caused by memcpy()
> based on outdated old_{rows,row_size} values, for resize_screen() can
> recurse into vc_do_resize() which changes vc->vc_{cols,rows} that outdates
> old_{rows,
On 30-07-20, 10:36, Lukasz Luba wrote:
> On 7/30/20 10:10 AM, Sudeep Holla wrote:
> > On Thu, Jul 30, 2020 at 02:23:33PM +0530, Viresh Kumar wrote:
> > > On 29-07-20, 16:12, Lukasz Luba wrote:
> > > > The existing CPUFreq framework does not tracks the statistics when the
> > > > 'fast switch' is us
On 11.07.20 00:34, Stefano Stabellini wrote:
From: Stefano Stabellini
xen_dma_sync_for_cpu, xen_dma_sync_for_device, xen_arch_need_swiotlb are
getting called passing dma addresses. On some platforms dma addresses
could be different from physical addresses. Before doing any operations
on these a
On 11.07.20 00:34, Stefano Stabellini wrote:
From: Stefano Stabellini
XEN_PFN_PHYS is only used in one place in swiotlb-xen making things more
complex than need to be.
Remove the definition of XEN_PFN_PHYS and open code the cast in the one
place where it is needed.
Signed-off-by: Stefano Stab
On Mon, Aug 03, 2020 at 04:51:27PM -0400, Michael S. Tsirkin wrote:
> On Tue, Jul 28, 2020 at 09:05:29AM +0300, Eli Cohen wrote:
> > Hi Michael,
> > please note that this series depends on mlx5 core device driver patches
> > in mlx5-next branch in
> > git://git.kernel.org/pub/scm/linux/kernel/git/m
On 11.07.20 00:34, Stefano Stabellini wrote:
From: Stefano Stabellini
With some devices physical addresses are different than dma addresses.
To be able to deal with these cases, we need to call phys_to_dma on
physical addresses (including machine addresses in Xen terminology)
before returning t
On Mon, Aug 03, 2020 at 04:34:50PM -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 29, 2020 at 08:54:52AM +0300, Eli Cohen wrote:
> > On Tue, Jul 28, 2020 at 02:53:34PM +0800, Jason Wang wrote:
> > >
> > > Just notice Michael's vhost branch can not compile due to this commit:
> > >
> > > commit fe
On 2020-08-03, Andi Kleen wrote:
Why is that? Both .text and .text.hot have alignment of 2^4 (default
function alignment on x86) by default, so it doesn't seem like it should
matter for packing density. Avoiding interspersing cold text among
You may lose part of a cache line on each unit bound
Sorry, I have been away for a while, but I will look at it shortly.
On 3/08/20 10:23 pm, Shirley Her (SC) wrote:
> Hi, Adrian:
>
> Do you have chance to review the patched code?
>
> Thanks,
> Shirley
>
>
> *From:* Shir
Currently, there is no other option to change the lower limit of
IOVA for any device than calling iova_init_domain(), but the
said function will re-init whole domain and also doesn't track
the previously allocated IOVA before re-initing the domain.
There are cases where the device might not suppor
On 31-07-20, 13:14, Jon Hunter wrote:
> I have been doing some more testing on Tegra, I noticed that when
> reading the current CPU frequency via the sysfs scaling_cur_freq entry,
> this always returns the cached value (at least for Tegra). Looking at
> the implementation of scaling_cur_freq I see
If the hardware watchdog in the clock chip simply pulls the reset line
of the CPU, then there is no chance to write a stack trace to help
determine what may have been blocking the CPU.
This patch adds a pretimeout to the watchdog, which, if enabled, sets
a timer to go off before the hardware watch
ommit
bba6f4f52c31 ("rpmsg: move common structures and defines to headers")
I have used the vhost tree from next-20200803 for today.
--
Cheers,
Stephen Rothwell
pgp7ZJAeJ9Tw9.pgp
Description: OpenPGP digital signature
On Mon, 2020-08-03 at 14:15 +0800, Crystal Guo wrote:
> Add ti_syscon_reset() to integrate assert and deassert together.
> If some modules need do serialized assert and deassert operations
> to reset itself, reset_control_reset can be called for convenience.
>
> Change-Id: I9046992b115a46f3594de57
Hi all,
Today's linux-next merge of the vhost tree got a conflict in:
drivers/scsi/virtio_scsi.c
between commit:
92e8d0323a51 ("scsi: virtio_scsi: Remove unnecessary condition check")
from the scsi tree and commit:
3dfd411ea7ec ("scsi: virtio_scsi: remove unnecessary condition check")
The crash_exclude_mem_range() can only handle one memory region one time.
It will fail the case in which the passed in area covers several memory
regions. In the case, it will only exclude the first region, then return,
but leave the later regions unsolved.
E.g in a NEC system with two usable RAM
Currently, when we enable the debugging switch to debug kexec_file,
always get the following wrong results:
kexec_file: Crash PT_LOAD elf header. phdr=c988639b vaddr=0x0,
paddr=0x0, sz=0x0 e_phnum=51 p_offset=0x0
kexec_file: Crash PT_LOAD elf header. phdr=3cca69a0 vaddr=0x0,
padd
This series includes the following patches, it fixes some corners bugs
and improves the crash_exclude_mem_range().
[1] [PATCH 1/3] x86/crash: Correct the address boundary of function
parameters
[2] [PATCH 2/3] kexec: Improve the crash_exclude_mem_range() to handle
the overlapping ranges
[3
Let's carefully handle the boundary of the function parameter to make
sure that the arguments passed doesn't exceed the address range.
Signed-off-by: Lianbo Jiang
---
arch/x86/kernel/crash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/crash.c b/arch/x86/ke
Thanks
在 2020/8/4 下午12:37, Viresh Kumar 写道:
On 04-08-20, 10:37, Xin Hao wrote:
Hi everyone:
I want to know why my patch didn't merge into upstream ?
I have sent a pull request earlier today to Rafael and this will get
merged in the next pull request Rafael will send to Linus.
On 8/4/20 12:22, Herbert Xu wrote:
> On Tue, Aug 04, 2020 at 12:20:21PM +0800, Liwei Song wrote:
>>
>> Yes, the other process should do this zero work, but the case I met is
>> this address will appear in the slab_alloc_node() as freelist pointer of
>> slub,
>> and before slub do zero wrok, eve
> Why is that? Both .text and .text.hot have alignment of 2^4 (default
> function alignment on x86) by default, so it doesn't seem like it should
> matter for packing density. Avoiding interspersing cold text among
You may lose part of a cache line on each unit boundary. Linux has
a lot of units
On 04-08-20, 10:37, Xin Hao wrote:
> Hi everyone:
>
> I want to know why my patch didn't merge into upstream ?
I have sent a pull request earlier today to Rafael and this will get
merged in the next pull request Rafael will send to Linus.
--
viresh
--
Dear friend do you receive my last message? write me back to my email
let me know.
--
Dear friend do you receive my last message? write me back to my email
let me know.
>
> For avoid further misunderstanding: it's fine that CRAS *uses* such a short
> period. It's often required for achieving a short latency.
>
> However, the question is whether the driver can set *only* this value for
> making it working. IOW, if we don't have this constraint, what actually
>
commit 742af7e7a0a1 ("arm64: tegra: Add Tegra210 support")
Tegra210 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.
Tegra SDMMC advertises 12Mhz as timeout clock frequency in host
capability register.
So, this clock should be
commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
Tegra210 and later has a separate sdmmc_legacy_tm (TMCLK) used by Tegra
SDMMC hawdware for data timeout to achive better timeout than using
SDCLK and using TMCLK is recommended.
USE_TMCLK_FOR_DATA_TIMEOUT bit in Tegra SDMMC register
SDHCI_T
commit 4346b7c7941d ("mmc: tegra: Add Tegra186 support")
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra186 from the
beginning of its support in driver.
Tegra186 SDMMC hardware by default uses timeout clock (TMCLK) instead
of SDCLK and this quirk should not be set.
So, this patch remove thi
commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra210 from the
beginning of Tegra210 support in the driver.
Tegra210 SDMMC hardware by default uses timeout clock (TMCLK)
instead of SDCLK and this quirk should not be set.
So, this patch r
commit 5425fb15d8ee ("arm64: tegra: Add Tegra194 chip device tree")
Tegra194 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.
Tegra194 SDMMC advertises 12Mhz as timeout clock frequency in host
capability register.
So, this clo
commit 39cb62cb8973 ("arm64: tegra: Add Tegra186 support")
Tegra186 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.
Tegra186 SDMMC advertises 12Mhz as timeout clock frequency in host
capability register and uses it by default.
Tegra210/Tegra186/Tegra194 has incorrectly enabled
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK from the beginning of their support.
Tegra210 and later SDMMC hardware default uses sdmmc_legacy_tm (TMCLK)
all the time for hardware data timeout instead of SDCLK and this TMCLK
need to be kept enabled by Tegra
The OpenRISC user access functions put_user(), get_user() and
clear_user() were missing proper sparse annotations. This generated
warnings like the below.
This patch adds the annotations to fix the warnings.
Example warnings:
net/ipv4/ip_sockglue.c:759:29: warning: incorrect type in argument 1
Hello,
This a series of fixes for OpenRISC sparse warnings. The kbuild robots report
many issues related to issues with OpenRISC headers having missing or incorrect
sparse annotations.
Example kdbuild-all report:
net/ipv4/ip_sockglue.c:1489:13: sparse: sparse: incorrect type in initializer
(
The __user annotations in signal.c were mostly missing. The missing
annotations caused the warnings listed below. This patch fixes them up
by adding the __user annotations.
arch/openrisc/kernel/signal.c:71:38: warning: incorrect type in initializer
(different address spaces)
arch/openrisc/kerne
Now that __user annotations are fixed for openrisc uaccess api's we can
add checking to the access_ok macro. This patch adds the __chk_user_ptr
check, on normal builds the added check is a nop.
Signed-off-by: Stafford Horne
---
arch/openrisc/include/asm/uaccess.h | 3 ++-
1 file changed, 2 inse
As suggested by Linus when reviewing commit 9cb2feb4d21d
("arch/openrisc: Fix issues with access_ok()") last year; making
__range_ok an inline function also fixes the used twice issue that the
commit was fixing. I agree it's a good cleanup. This patch addresses
that as I am currently working on t
1 - 100 of 1559 matches
Mail list logo
