Remove the now unused check_disk_change helper.
Signed-off-by: Christoph Hellwig
Reviewed-by: Johannes Thumshirn
---
fs/block_dev.c| 20
include/linux/genhd.h | 1 -
2 files changed, 21 deletions(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index c6ac0bd22eca70
Change since v17:
- modify how to get keycode in keypad interrupt handler
- replace variable ret as error in probe function
- update keypad, num-columns and keypad, num-rows descriptioin
fengping.yu (3):
dt-bindings: Add bindings for Mediatek matrix keypad
drivers: input:keyboard: Add mtk key
Switch to use bdev_check_media_change instead of check_disk_change and
call floppy_revalidate manually. Given that floppy_revalidate only
deals with media change events, the extra call into ->revalidate_disk
from bdev_disk_changed is not required either, so stop wiring up the
method.
Signed-off-b
Switch to use bdev_check_media_changed instead of check_disk_change and
call floppy_revalidate manually. Given that floppy_revalidate only
deals with media change events, the extra call into ->revalidate_disk
from bdev_disk_changed is not required either, so stop wiring up the
method.
Signed-off-
On 9/5/20 12:39 PM, Jonathan Marek wrote:
The driver may be used without slimbus, so don't depend on slimbus.
Signed-off-by: Jonathan Marek
---
drivers/soundwire/Kconfig | 2 +-
drivers/soundwire/qcom.c | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/soun
On 2020-9-8 10:44, Daeho Jeong wrote:
From: Daeho Jeong
writepages() can be concurrently invoked for the same file by different
threads such as a thread fsyncing the file and a kworker kernel thread.
So, changing i_compr_blocks without protection is racy and we need to
protect it by changing it
On Tue, Sep 08, 2020 at 09:47:13AM -0500, Pierre-Louis Bossart wrote:
> On 9/8/20 9:33 AM, Mark Brown wrote:
> > On Tue, Sep 08, 2020 at 02:28:48PM +0200, Jaroslav Kysela wrote:
> > > Dne 08. 09. 20 v 14:11 Mark Brown napsal(a):
> > > > I don't have this patch and since I seem to get copied on qui
On 2020-09-08 16:56:20 [+0200], Mike Galbraith wrote:
> On Tue, 2020-09-08 at 14:19 +0200, Sebastian Andrzej Siewior wrote:
> >
> > This has nothing to do with the bridge but with the fact that you use a
> > non standard queue class (something else than pfifo_fast).
>
> That must be SUSE, I don't
On 9/8/2020 2:02 PM, Keita Suzuki wrote:
Thank you for your comment. I am relatively new to the Linux
kernel community, so I am more than happy to receive comments.
Please let me know if I'm violating any other rules.
Sure ;-)
Here a useful link that Kalle (wireless drivers maintainer) is alwa
On Tue, Sep 08, 2020 at 03:07:49PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> If the module init function fails after creating the debugs directory,
> it's never removed. Add proper cleanup calls to avoid this resource
> leak.
Reviewed-by: Andy Shevchenko
> Fixes: 9202ba
We soon want to pass flags, e.g., to mark added System RAM resources.
mergeable. Prepare for that.
This patch is based on a similar patch by Oscar Salvador:
https://lkml.kernel.org/r/20190625075227.15193-3-osalva...@suse.de
Acked-by: Wei Liu
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Dan Williams
Let's try to merge system ram resources we add, to minimize the number
of resources in /proc/iomem. We don't care about the boundaries of
individual chunks we added.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Wei Liu
Cc: Pankaj Gupta
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs, exposed
virtio-mem adds memory in memory block granularity, to be able to
remove it in the same granularity again later, and to grow slowly on
demand. This, however, results in quite a lot of resources when
adding a lot of memory. Resources are effectively stored in a list-based
tree. Having a lot of resou
On Tue, Sep 8, 2020 at 12:44 PM wrote:
>
> On 2020-09-07 10:04, Rob Clark wrote:
> > From: Rob Clark
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 81
> > 1 file changed, 12 insertions(+), 69 deletions(-)
> >
> > diff --git a/dr
Let's try to merge system ram resources we add, to minimize the number
of resources in /proc/iomem. We don't care about the boundaries of
individual chunks we added.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Roger Pau Monné
Cc: Julien
IORESOURCE_MEM_DRIVER_MANAGED currently uses an unused PnP bit, which is
always set to 0 by hardware. This is far from beautiful (and confusing),
and the bit only applies to SYSRAM. So let's move it out of the
bus-specific (PnP) defined bits.
We'll add another SYSRAM specific bit soon. If we ever
Let's make sure splitting a resource on memory hotunplug will never fail.
This will become more relevant once we merge selected System RAM
resources - then, we'll trigger that case more often on memory hotunplug.
In general, this function is already unlikely to fail. When we remove
memory, we free
GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
These are simple defines so they could be used in DTS but they will not
have the same meaning:
1. GPIO_ACTIVE_HIGH = 0 = IRQ_TYPE_NONE
2. GPIO_ACTIVE_LOW = 1 = IRQ_TYPE_EDGE_RISING
Correct the interrupt flags, assuming the aut
On Tue, Sep 08, 2020 at 03:50:48AM -0400, Ethan Zhao wrote:
> From: Ethan Zhao
>
> 'commit e8c7d14ac6c3 ("block: revert back to synchronous request_queue
> removal")' introduced panic issue to NVMe hotplug as following(hit
> after just 2 times NVMe SSD hotplug under stable 5.9-RC2):
I'm pretty s
The gpioledgrp in iomux is not used, so it can be dropped.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
b/arch/arm64/boot/dts/fr
GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
These are simple defines so they could be used in DTS but they will not
have the same meaning:
1. GPIO_ACTIVE_HIGH = 0 = IRQ_TYPE_NONE
2. GPIO_ACTIVE_LOW = 1 = IRQ_TYPE_EDGE_RISING
Correct the interrupt flags without affecting
GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
These are simple defines so they could be used in DTS but they will not
have the same meaning:
1. GPIO_ACTIVE_HIGH = 0 = IRQ_TYPE_NONE
2. GPIO_ACTIVE_LOW = 1 = IRQ_TYPE_EDGE_RISING
Correct the interrupt flags, assuming the aut
On 9/8/20 7:44 AM, Stefano Garzarella wrote:
> Hi Jens,
>
> On Thu, Aug 27, 2020 at 04:58:31PM +0200, Stefano Garzarella wrote:
>> This patch adds a new IORING_SETUP_R_DISABLED flag to start the
>> rings disabled, allowing the user to register restrictions,
>> buffers, files, before to start proce
On 0908, Bjorn Andersson wrote:
> On Tue 08 Sep 02:57 CDT 2020, Manivannan Sadhasivam wrote:
>
> > Document the SM8250 SoC specific compatible for Qualcomm Cpufreq HW. The
> > hardware block which carries out CPUFreq operations on SM8250 SoC is
> > called EPSS.
> >
> > Signed-off-by: Manivannan S
On 0908, Amit Kucheria wrote:
> On Tue, Sep 8, 2020 at 1:27 PM Manivannan Sadhasivam
> wrote:
> >
> > For preparing the driver to handle further SoC revisions, let's use the
> > of_match data for getting the device specific offsets and row size instead
> > of defining them globally.
> >
> > Signed
bq27000, bq27010 and upcoming bq34z100 have a single byte SoC
register. However except this similarity, bq34z100 is quite different
than bq27000/bq27010, so flag BQ27XXX_O_ZERO cannot be reused here. Add
a new bit flag describing that SoC is a single byte register.
No functional change for bq270
No functional change.
Signed-off-by: Krzysztof Kozlowski
---
drivers/power/supply/bq27xxx_battery.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/supply/bq27xxx_battery.c
b/drivers/power/supply/bq27xxx_battery.c
index 65806f668b1f..2deac3fbb036 100644
--- a/d
BIT() is a preferred way to toggle bit-like flags: no problems with 32/64
bit systems, less chances for mistakes.
Signed-off-by: Krzysztof Kozlowski
---
drivers/power/supply/bq27xxx_battery.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/power/supply
bq27000, bq27010 and upcoming bq34z100 have a Capacity Inaccurate flag.
However except this similarity, bq34z100 is quite different than
bq27000/bq27010, so flag BQ27XXX_O_ZERO cannot be reused here. Add
a new bit flag describing this capability.
No functional change for bq27000 and bq27010.
Sig
Add support for new device: the TI bq34z100-G1, a Wide Range Fuel Gauge
for Li-Ion, PbA, NiMH, and NiCd batteries. The device shares a lot with
other models, although it has its own differences requiring new quirks.
This patch was tested on a system equipped with NiMH batteries.
Signed-off-by: K
Add compatible for bq34z100 charger.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/power/supply/bq27xxx.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml
b/Documentation/devicetree/bindings/power/suppl
For non root CG, in try_charge(), we keep trying
to charge until we succeed. On non-preemptive
kernel, when we are OOM, this results in holding
CPU forever.
On SMP systems, this doesn't create a big problem
because oom_reaper get a change to kill victim
and make some free pages. However on a singl
On Tue, 2020-09-08 at 14:19 +0200, Sebastian Andrzej Siewior wrote:
>
> This has nothing to do with the bridge but with the fact that you use a
> non standard queue class (something else than pfifo_fast).
That must be SUSE, I don't muck about in network land. I downloaded a
whole library of RFCs
drop_caches by its very nature can be extremely performance intensive -- if
someone wants to abort after trying too long, they can just send a
TASK_KILLABLE signal, no? If exiting the loop and returning to usermode doesn't
reliably work when doing that, then _that's_ something to improve, but th
Commit 6f24ff97e323 ("power: supply: bq27xxx_battery: Add the
BQ27Z561 Battery monitor") and commit d74534c27775 ("power:
bq27xxx_battery: Add support for additional bq27xxx family devices")
added support for new device types by copying most of the code and
adding necessary quirks.
However they di
Fixes the following W=1 kernel build warning(s):
net/netlabel/netlabel_calipso.c:438: warning: Excess function parameter
'audit_secid' description in 'calipso_doi_remove'
net/netlabel/netlabel_calipso.c:605: warning: Excess function parameter 'reg'
description in 'calipso_req_delattr'
Reported-
Replying to myself:
This is 5.9.0-rc3-00091-ge28f0104343d on Lenovo t460s that has ran fine up to
5.8.0.
Now I reproduced the same problem with 5.9.0-rc3 on a HP desktop with Core2Quad
CPU. The call trace is very similar and it's crashing gcc again while compiling
5.9-rc4.
But it seems 5.9-
From: Billows Wu
This series adds PCIe controller driver for Unisoc SoCs.
This controller is based on DesignWare PCIe IP.
Signed-off-by: Billows Wu
---
drivers/pci/controller/dwc/Kconfig | 13 ++
drivers/pci/controller/dwc/Makefile| 1 +
drivers/pci/controller/dwc/pcie-sprd.c | 231
On 17:52-20200907, Roger Quadros wrote:
> The SERDES lane control mux registers are present in the
> CTRLMMR space.
>
> Signed-off-by: Roger Quadros
> ---
> arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti
The pull request you sent on Tue, 08 Sep 2020 08:18:44 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d6dc7e06826bd7bbb654b7a730db99e7020abbf6
Thank you!
--
Deet-doot-dot, I am a bot.
ht
On Tue, 8 Sep 2020 12:37:36 +0200
pet...@infradead.org wrote:
> On Thu, Sep 03, 2020 at 10:39:54AM +0900, Masami Hiramatsu wrote:
>
> > > There's a bug, that might make it miss it. I have a patch. I'll send it
> > > shortly.
> >
> > OK, I've confirmed that the lockdep warns on kretprobe from INT
Convert the RN5T618 binding to DT schema format. Also
clearly state which regulators are available.
Signed-off-by: Andreas Kemnade
---
I have noted myself here as maintainer because I wrote most of the
code of the several subdevices, although not of the .txt-binding.
Due to its .txt-format histor
On Tue, 8 Sep 2020 01:47:08 +0530
Ajay Kaher wrote:
> CVE-2020-12888 Kernel: vfio: access to disabled MMIO space of some
> devices may lead to DoS scenario
>
> The VFIO modules allow users (guest VMs) to enable or disable access to the
> devices' MMIO memory address spaces. If a user attempt
My Dear in the lord
My name is Mrs. Mina A. Brunel I am a Norway Citizen who is living in Burkina
Faso, I am married to Mr. Brunel Patrice, a politicians who owns a small gold
company in Burkina Faso; He died of Leprosy and Radesyge, in year February
2010, During his lifetime he deposited t
Hello,
syzbot found the following issue on:
HEAD commit:f4d51dff Linux 5.9-rc4
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1455d4f990
kernel config: https://syzkaller.appspot.com/x/.config?x=a9075b36a6ae26c9
dashboard link: https://syzkaller.appspot
On Thu, Aug 27, 2020 at 12:38 PM Catalin Marinas
wrote:
>
> On Fri, Aug 14, 2020 at 07:27:06PM +0200, Andrey Konovalov wrote:
> > @@ -957,6 +984,7 @@ SYM_FUNC_START(cpu_switch_to)
> > mov sp, x9
> > msr sp_el0, x1
> > ptrauth_keys_install_kernel x1, x8, x9, x10
> > +
On Tue, 8 Sep 2020 02:05:17 +0530
Ajay Kaher wrote:
> CVE-2020-12888 Kernel: vfio: access to disabled MMIO space of some
> devices may lead to DoS scenario
>
> The VFIO modules allow users (guest VMs) to enable or disable access to the
> devices' MMIO memory address spaces. If a user attempt
On 7 Sep 2020, at 3:20, Michal Hocko wrote:
> On Fri 04-09-20 14:10:45, Roman Gushchin wrote:
>> On Fri, Sep 04, 2020 at 09:42:07AM +0200, Michal Hocko wrote:
> [...]
>>> An explicit opt-in sounds much more appropriate to me as well. If we go
>>> with a specific API then I would not make it 1GB pa
On Wed, Sep 02, 2020 at 06:48:30AM -0700, Guenter Roeck wrote:
> On 9/2/20 2:12 AM, pet...@infradead.org wrote:
> > On Wed, Sep 02, 2020 at 11:09:35AM +0200, pet...@infradead.org wrote:
> >> On Tue, Sep 01, 2020 at 09:21:37PM -0700, Guenter Roeck wrote:
> >>> [0.00] WARNING: CPU: 0 PID: 0 a
Change from v9:
- rename timestamp to ts in binder_internal.h for conciseness.
- change 'struct timeval' to 'struct timespec64' in binder_internal.h.
Change from v8:
- change rtc_time_to_tm to rtc_time64_to_tm.
- change timeval to __kernel_old_timeval due to
https://git.kernel.org/pu
On Tue 08 Sep 02:57 CDT 2020, Manivannan Sadhasivam wrote:
> Document the SM8250 SoC specific compatible for Qualcomm Cpufreq HW. The
> hardware block which carries out CPUFreq operations on SM8250 SoC is
> called EPSS.
>
> Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Bjorn Andersson
Ple
On Sat, Sep 05, 2020 at 06:48:35PM -0400, Arvind Sankar wrote:
> On Tue, Sep 01, 2020 at 07:53:46PM -0700, Kees Cook wrote:
> > We don't want to depend on the linker's orphan section placement
> > heuristics as these can vary between linkers, and may change between
> > versions. All sections need t
On 9/8/20 8:40 PM, Andy Shevchenko wrote:
On Tue, Sep 8, 2020 at 8:20 PM Maximilian Luz wrote:
...
+ .gpe_number = 0x17,
+ .gpe_number = 0x4D,
+ .gpe_number = 0x4F,
+ .gpe_number = 0x57,
From where these numbers come from? Can we get them from firmware (ACPI)?
Ye
On Mon, Sep 07, 2020 at 08:08:50PM +0800, Jianjun Wang wrote:
> Add YAML schemas documentation for Gen3 PCIe controller on
> MediaTek SoCs.
dt-bindings: PCI: mediatek: ... for the subject.
>
> Acked-by: Ryder Lee
> Signed-off-by: Jianjun Wang
> ---
> .../bindings/pci/mediatek-pcie-gen3.yaml
On Tue, Sep 08, 2020 at 12:35:18PM -0700, Kees Cook wrote:
> While we testing for the behavior of unknown seccomp filter return
s/we/we're/
> values, there was no test for how it acted in a thread group. Add
> a test in the thread group tests for this.
>
> Signed-off-by: Kees Cook
> ---
> (This
Hi,
On Mon, Sep 07, 2020 at 09:34:02AM +0200, Neil Armstrong wrote:
> The AXG Analog MIPI-DSI PHY also provides functions to the PCIe PHY,
> thus we need to have inclusive support for both interfaces at runtime.
>
> This fixes the regmap get from parent node, removes cell param
> to select a mode
On Mon, 07 Sep 2020 18:11:18 +0200, Krzysztof Kozlowski wrote:
> The ADC in S3C/S5P/Exynos SoCs can be used also for handling touch
> screen. In such case the second interrupt is required. This second
> interrupt can be anyway provided, even without touch screens. This
> fixes dtbs_check warning
On Mon, Sep 07, 2020 at 06:11:18PM +0200, Krzysztof Kozlowski wrote:
> The ADC in S3C/S5P/Exynos SoCs can be used also for handling touch
> screen. In such case the second interrupt is required. This second
> interrupt can be anyway provided, even without touch screens. This
> fixes dtbs_check w
The wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below and has been
hand modified to replace GFP_ with a correct flag.
It has been compile tested.
When memory is allocated in 'tc35815_init_queues()' GFP_ATOMIC must be used
beca
Move the internal get_data() function as-is above prb_reserve() so
that a later change can make use of the static function.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
kernel/printk/printk_ringbuffer.c | 116 +++---
1 file changed, 58 insertions(+), 58 deleti
prb_reserve() will set some meta data values and leave others
uninitialized (or rather, containing the values of the previous
wrap). Simplify the API by always clearing out all the fields.
Only the sequence number is filled in. The caller is now
responsible for filling in the rest of the meta data
Rather than continually needing to explicitly check @begin and @next
to identify a dataless block, introduce and use a BLK_DATALESS()
macro.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
kernel/printk/printk_ringbuffer.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
dif
Add support for extending the newest data block. For this, introduce
a new finalization state (desc_finalized) denoting a committed
descriptor that cannot be extended.
Until a record is finalized, a writer can reopen that record to
append new data. Reopening a record means transitioning from the
d
Use the record extending feature of the ringbuffer to implement
continuous messages. This preserves the existing continuous message
behavior.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
kernel/printk/printk.c | 98 +-
1 file changed, 20 insert
Rather than deriving the state by evaluating bits within the flags
area of the state variable, assign the states explicit values and
set those values in the flags area. Introduce macros to make it
simple to read and write state values for the state variable.
Although the functionality is preserved
Hello,
Here is v4 for the second series to rework the printk subsystem.
(The v3 is here [0].) This series implements a new ringbuffer
feature that allows the last record to be extended. Petr Mladek
provided the initial proof of concept [1] for this.
Using the record extension feature, LOG_CONT is
Add a new SKU variant. This is a pick from the downstream tree that
is the current source of truth for this platform.
Link: https://crrev.com/c/2386997
Signed-off-by: Douglas Anderson
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../dts/qcom/sc7180-trogdor-lazor-r1-kb.dts |
On Tue, Sep 8, 2020 at 1:14 PM Julius Hemanth Pitti wrote:
>
> For non root CG, in try_charge(), we keep trying
> to charge until we succeed. On non-preemptive
> kernel, when we are OOM, this results in holding
> CPU forever.
>
> On SMP systems, this doesn't create a big problem
> because oom_reap
On Thu, 30 Jul 2020 at 16:32, Dan Murphy wrote:
>
> Fix spacing style issues with the chip data array. As well as fix
> missing new line after variable declaration.
>
> Signed-off-by: Dan Murphy
> ---
> drivers/power/supply/bq27xxx_battery.c | 63 ++
> 1 file changed, 33
If something goes wrong (such as the SCL being stuck low) then we need
to reset the PCA chip. The issue with this is that on reset we lose all
config settings and the chip ends up in a disabled state which results
in a lock up/high CPU usage. We need to re-apply any configuration that
had previousl
On Mon, Sep 07, 2020 at 06:00:38PM +0800, Cheng-Yi Chiang wrote:
> Add devicetree bindings documentation file for sc7180 sound card.
>
> Signed-off-by: Cheng-Yi Chiang
> ---
> .../bindings/sound/qcom,sc7180.yaml | 143 ++
> 1 file changed, 143 insertions(+)
> create mo
> On Sep 8, 2020, at 12:30 PM, Borislav Petkov wrote:
>
> On Tue, Sep 08, 2020 at 12:18:38PM -0700, Sultan Alsawaf wrote:
>> I'd like to point out that on Intel's recent 14nm parts, undervolting
>> is not so much for squeezing every last drop of performance out of the
>> SoC as it is for nece
On Thu, Aug 20, 2020 at 11:11:48AM -0500, Eddie James wrote:
> Document the bindings for the IBM Operation Panel, which provides
> a simple interface to control a server. It has a display and three
> buttons.
> Also update MAINTAINERS for the new file.
>
> Signed-off-by: Eddie James
> ---
> .../
Hi Eddie,
> + switch (event) {
> + case I2C_SLAVE_STOP:
> + command_size = panel->idx;
> + fallthrough;
> + case I2C_SLAVE_WRITE_REQUESTED:
> + panel->idx = 0;
> + break;
> + case I2C_SLAVE_WRITE_RECEIVED:
> + if (panel->i
Krzysztof
On 9/8/20 3:32 PM, Krzysztof Kozlowski wrote:
On Thu, 30 Jul 2020 at 16:32, Dan Murphy wrote:
Fix spacing style issues with the chip data array. As well as fix
missing new line after variable declaration.
Signed-off-by: Dan Murphy
---
drivers/power/supply/bq27xxx_battery.c | 63
On Thu, Aug 20, 2020 at 12:02:25PM -0500, Eddie James wrote:
> Add documentation for the "fsi2spi,restricted" property which indicates
> a controller shouldn't sequence loops and therefore has a smaller
> transfer size.
>
> Signed-off-by: Eddie James
> Acked-by: Joel Stanley
> Signed-off-by: Joe
On Mon, Sep 07, 2020 at 10:23:13PM +0800, Xu Yilun wrote:
> A new bus type "dfl" is introduced for private features which are not
> initialized by DFL feature drivers (dfl-fme & dfl-afu drivers). So these
> private features could be handled by separate driver modules.
>
> DFL feature drivers (dfl-
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f4d51dffc6c01a9e94650d95ce0104964f8ae822
commit: 08fef4fa947ba75cbf59d67c6be75223c6471a88 media: atomisp: get rid of
memory_access.c
date: 3 months ago
config: i386-randconfig-a002-20200909 (attached as .c
On Fri, Aug 21, 2020 at 12:55:43AM +0200, Alexandre Belloni wrote:
> Move the TCB pwm nodes under their parent and move its documentation to the
> main file.
>
> Signed-off-by: Alexandre Belloni
> ---
> Cc: Rob Herring
>
> .../devicetree/bindings/pwm/atmel-tcb-pwm.txt | 16 --
> .../so
From: Dexuan Cui Sent: Monday, September 7, 2020 12:14 AM
>
> mlx5_suspend()/resume() keep the network interface, so during hibernation
> netvsc_unregister_vf() and netvsc_register_vf() are not called, and hence
> netvsc_resume() should call netvsc_vf_changed() to switch the data path
> back to
On Fri, Aug 21, 2020 at 06:44:36PM +0800, Hsin-Hsiung Wang wrote:
> This adds documentation for the SPMI controller found on Mediatek SoCs.
>
> Signed-off-by: Hsin-Hsiung Wang
> ---
> .../devicetree/bindings/spmi/spmi-mtk-pmif.txt | 33
> ++
> 1 file changed, 33 insertio
On Tue, Sep 8, 2020 at 12:47 PM Pavel Machek wrote:
> > +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> > @@ -6836,16 +6836,19 @@ static ssize_t bnxt_show_temp(struct device *dev,
> ...
> > - return sprintf(buf, "%u\n", temp);
> > + if (len)
> > + return len;
> > +
> > +
Impose a maximum on the number of client rxrpc calls that are allowed
simultaneously. This will be in lieu of a maximum number of client
connections as this is easier to administed as, unlike connections, calls
aren't reusable (to be changed in a subsequent patch)..
This doesn't affect the limits
mber is tunable by sysctl.
[*] Technically two limits - kernel sockets and userspace rxrpc sockets are
accounted separately.
The patches are tagged here:
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
rxrpc-next-20200908
and can also be found on th
Rewrite the rxrpc client connection manager so that it can support multiple
connections for a given security key to a peer. The following changes are
made:
(1) For each open socket, the code currently maintains an rbtree with the
connections placed into it, keyed by communications parameter
Allow the number of parallel connections to a machine to be expanded from a
single connection to a maximum of four. This allows up to 16 calls to be
in progress at the same time to any particular peer instead of 4.
Signed-off-by: David Howells
---
net/rxrpc/conn_client.c |6 ++
1 file
On Tue 08-09-20 13:31:51, Yang Shi wrote:
> On Tue, Sep 8, 2020 at 1:14 PM Julius Hemanth Pitti wrote:
> >
> > For non root CG, in try_charge(), we keep trying
> > to charge until we succeed. On non-preemptive
> > kernel, when we are OOM, this results in holding
> > CPU forever.
> >
> > On SMP sys
On 2020-09-08 13:11, Rob Clark wrote:
On Tue, Sep 8, 2020 at 12:44 PM wrote:
On 2020-09-07 10:04, Rob Clark wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
Reviewed-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 81
> 1 file changed,
Krzysztof
On 9/8/20 3:13 PM, Krzysztof Kozlowski wrote:
BIT() is a preferred way to toggle bit-like flags: no problems with 32/64
bit systems, less chances for mistakes.
Signed-off-by: Krzysztof Kozlowski
---
drivers/power/supply/bq27xxx_battery.c | 15 ---
1 file changed, 8 ins
Krzysztof
On 9/8/20 3:13 PM, Krzysztof Kozlowski wrote:
Commit 6f24ff97e323 ("power: supply: bq27xxx_battery: Add the
BQ27Z561 Battery monitor") and commit d74534c27775 ("power:
bq27xxx_battery: Add support for additional bq27xxx family devices")
added support for new device types by copying mos
'make M=/path/to/your/external/module' creates a pointless built-in.a
in the top of the external module directory because KBUILD_BUILTIN is
set to 1.
Clear KBUILD_BUILTIN when we are building external modules so that
'make M=...' and 'make M=... modules' work equivalently.
Signed-off-by: Masahiro
On Thu, Sep 03, 2020 at 03:19:43PM -0700, Kees Cook wrote:
> On Thu, Sep 03, 2020 at 01:30:36PM -0700, Sami Tolvanen wrote:
> > With LTO, LLVM bitcode won't be compiled into native code until
> > modpost_link, or modfinal for modules. This change postpones calls
> > to objtool until after these ste
On Tue, Sep 8, 2020 at 8:20 AM Christoph Hellwig wrote:
> > @@ -264,68 +266,24 @@ asmlinkage long sys_oabi_epoll_ctl(int epfd, int op,
> > int fd,
> > return do_epoll_ctl(epfd, op, fd, &kernel, false);
> > }
> >
> > -static long do_oabi_epoll_wait(int epfd, struct oabi_epoll_event __user
Sorry, I couldn't resist adding three more comments to improve further:
-static int skylake_nau8825_hw_params(struct snd_pcm_substream *substream,
- struct snd_pcm_hw_params *params)
+static int skylake_nau8825_trigger(struct snd_pcm_substream *substream, int
cmd)
{
struct snd_s
On Tue, Sep 08, 2020 at 11:42:00AM -0700, Linus Torvalds wrote:
> On Tue, Sep 8, 2020 at 11:32 AM Josh Poimboeuf wrote:
> >
> > Can you share the .o file? At least I can't recreate with GCC 9.3.1,
> > which is all I have at the moment.
>
> Done off-list in private, because I don't think anybody
On 08/09/2020 03:03, Hillf Danton wrote:
>
> On Mon, 7 Sep 2020 06:55:04 Jens Axboe wrote:
>> On 9/7/20 2:50 AM, Pavel Begunkov wrote:
>>>
>>> BTW, I don't see the patch itself, and it's neither in io_uring, block
>>> nor fs mailing lists. Hillf, could you please CC proper lists next time?
>
> Ye
On Tue, 2020-09-08 at 13:31 -0700, Yang Shi wrote:
> On Tue, Sep 8, 2020 at 1:14 PM Julius Hemanth Pitti > wrote:
> >
> > For non root CG, in try_charge(), we keep trying
> > to charge until we succeed. On non-preemptive
> > kernel, when we are OOM, this results in holding
> > CPU forever.
> >
>
From: Dexuan Cui Sent: Friday, September 4, 2020 7:56 PM
>
> After we Stop and later Start a VM that uses Accelerated Networking (NIC
> SR-IOV), currently the VF vmbus device's Instance GUID can change, so after
> vmbus_bus_resume() -> vmbus_request_offers(), vmbus_onoffer() can not find
> the or
NPS customers are no longer doing active development, as evident from
rand config build failures reported in recent times, so drop support
for NPS platform.
Signed-off-by: Vineet Gupta
---
MAINTAINERS | 7 -
arch/arc/Makefile | 5 -
arch/arc/
1401 - 1500 of 1827 matches
Mail list logo
