On Fri 04-10-19 09:56:00, Qian Cai wrote:
> On Fri, 2019-10-04 at 15:38 +0200, Michal Hocko wrote:
> > On Fri 04-10-19 09:30:39, Qian Cai wrote:
> > > On Fri, 2019-10-04 at 15:07 +0200, Michal Hocko wrote:
> > > > On Fri 04-10-19 08:56:16, Qian Cai wrote:
> > > > [...]
> > > > > It might be a good
On 18.3.2019 13.32, Appana Durga Kedareswara rao wrote:
> AXI CAN IP and CANPS IP supports tx fifo empty feature, this patch updates
> the flags field for the same.
>
> Signed-off-by: Appana Durga Kedareswara rao
> ---
> drivers/net/can/xilinx_can.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> d
Hillf Danton wrote:
> if (conn) {
> - rxrpc_disconnect_call(call);
> conn->security->free_call_crypto(call);
> + rxrpc_disconnect_call(call);
> }
Better to cache the security pointer in the call struct, I think.
David
On 10/4/19 6:45 AM, Changbin Du wrote:
> +static inline bool is_canonical_addr(u64 addr)
> +{
> +#ifdef CONFIG_X86_64
> + int shift = 64 - boot_cpu_data.x86_phys_bits;
I think you mean to check the virtual bits member, not "phys_bits".
BTW, I also prefer the IS_ENABLED(CONFIG_) checks to expl
On Wed, 18 Sep 2019, Jean-Jacques Hiblot wrote:
> From: Tomi Valkeinen
>
> This patch adds a led-backlight driver (led_bl), which is similar to
> pwm_bl except the driver uses a LED class driver to adjust the
> brightness in the HW. Multiple LEDs can be used for a single backlight.
>
> Signed-o
Em Fri, Oct 04, 2019 at 11:36:58AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Oct 04, 2019 at 03:30:07PM +0100, John Garry escreveu:
> > On 04/09/2019 16:54, John Garry wrote:
> > > This patchset adds some missing uncore PMU events for the hip08 arm64
> > > platform.
> > >
> > > The missi
On Thu, Oct 03, 2019 at 11:01:32AM +0200, Petr Mladek wrote:
> Hi,
>
> this is another piece in the puzzle that helps to maintain more
> livepatches.
>
> Especially pre/post (un)patch callbacks might change a system state.
> Any newly installed livepatch has to somehow deal with system state
> mo
Em Fri, Oct 04, 2019 at 03:30:07PM +0100, John Garry escreveu:
> On 04/09/2019 16:54, John Garry wrote:
> > This patchset adds some missing uncore PMU events for the hip08 arm64
> > platform.
> >
> > The missing events were originally mentioned in
> > https://lkml.org/lkml/2019/6/14/645, when upst
On Wed, 02 Oct 2019, Thierry Reding wrote:
> From: Thierry Reding
>
> regmap_add_irq_chip() will try to allocate all of the IRQ descriptors
> upfront if passed a non-zero irq_base parameter. However, the intention
> is to allocate IRQ descriptors on an as-needed basis if possible. Pass 0
> inste
On Thu, Oct 3, 2019 at 5:02 PM David Z. Dai wrote:
>
> On Thu, 2019-10-03 at 13:39 -0700, Alexander Duyck wrote:
> > On Thu, Oct 3, 2019 at 11:51 AM David Z. Dai
> > wrote:
> > >
> > > On Thu, 2019-10-03 at 10:39 -0700, Alexander Duyck wrote:
> > > > On Thu, Oct 3, 2019 at 9:59 AM David Dai
>
On Tue, 01 Oct 2019, Charles Keepax wrote:
> Add the ability to get the clock for each clock input pin of the chip
> and enable MCLK2 since that is expected to be a permanently enabled
> 32kHz clock.
>
> Signed-off-by: Charles Keepax
> ---
>
> Changes since v2:
> - Use new devm_clk_bulk_get_op
On Fri, Oct 04, 2019 at 03:27:48PM +0100, Al Viro wrote:
> On Fri, Oct 04, 2019 at 04:05:03PM +0200, Christian Brauner wrote:
> > From: Will Deacon
> >
> > Closing /dev/pts/ptmx removes the corresponding pty under /dev/pts/
> > without synchronizing against concurrent path walkers. This can lead
On 04/09/2019 16:54, John Garry wrote:
This patchset adds some missing uncore PMU events for the hip08 arm64
platform.
The missing events were originally mentioned in
https://lkml.org/lkml/2019/6/14/645, when upstreaming the JSONs initially.
It also includes a fix for a DDRC eventname.
Hi guy
On Fri, Oct 04, 2019 at 04:05:03PM +0200, Christian Brauner wrote:
> From: Will Deacon
>
> Closing /dev/pts/ptmx removes the corresponding pty under /dev/pts/
> without synchronizing against concurrent path walkers. This can lead to
> 'dcache_readdir()' tripping over a 'struct dentry' with a NULL
If the RTC HW returns an invalid time, the rtc_year_days()
call would crash. This patch adds error logging in this
situation, and removes the tm_yday and tm_wday calculations.
These fields should not be relied upon by userspace
according to man rtc, and thus we don't need to calculate
them.
Signed
> -Original Message-
> From: Limonciello, Mario
> Sent: Friday, October 4, 2019 9:06 AM
> To: 'Yehezkel Bernat'; Mika Westerberg
> Cc: linux-...@vger.kernel.org; Andreas Noever; Michael Jamet; Rajmohan Mani;
> nicholas.johnson-opensou...@outlook.com.au; Lukas Wunner;
> gre...@linuxfoundatio
+Christian
On Fri, Oct 04, 2019 at 02:05:46PM +, mario.limoncie...@dell.com wrote:
> >
> > On Fri, Oct 4, 2019 at 11:19 AM Mika Westerberg
> > wrote:
> > >
> > > On Fri, Oct 04, 2019 at 11:07:34AM +0300, Yehezkel Bernat wrote:
> > > > > Also if you can get the hw_vendor_id and hw_product_id
On Fri, Oct 04, 2019 at 03:32:04PM +0200, Rasmus Villemoes wrote:
> If I'm reading of_pwm_xlate_with_flags() right, existing device trees
> that set #pwm-cells = 2 will continue to work.
Yes, that's what I expect, too.
> Signed-off-by: Rasmus Villemoes
> ---
> drivers/pwm/pwm-mxs.c | 14 +++
On 04/10/2019 04:39, Soeren Moch wrote:
On 04.10.19 04:13, Shawn Lin wrote:
On 2019/10/4 8:53, Soeren Moch wrote:
On 04.10.19 02:01, Robin Murphy wrote:
On 2019-10-03 10:50 pm, Soeren Moch wrote:
According to the RockPro64 schematic [1] the rk3399 sdmmc
controller is
connected to a microS
On Fri, Oct 04, 2019 at 03:32:03PM +0200, Rasmus Villemoes wrote:
> Since we now have ->apply, these are no longer relevant.
>
> Signed-off-by: Rasmus Villemoes
nice and easy,
Reviewed-by: Uwe Kleine-König
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König
Hello,
On Fri, Oct 04, 2019 at 03:32:02PM +0200, Rasmus Villemoes wrote:
> In preparation for supporting setting the polarity, switch the driver
> to support the ->apply method.
>
> Signed-off-by: Rasmus Villemoes
> ---
> drivers/pwm/pwm-mxs.c | 70 +++
>
Em Fri, 4 Oct 2019 15:50:18 +0200
JP escreveu:
> On 10/4/19 2:08 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 4 Oct 2019 13:50:43 +0200
> > JP escreveu:
> >
> >> On 10/3/19 10:03 PM, Mauro Carvalho Chehab wrote:
> >>> Em Thu, 3 Oct 2019 21:51:35 +0200
> >>> Gonsolo escreveu:
> >>>
> >>
On Fri, Oct 04, 2019 at 03:32:07PM +0200, Rasmus Villemoes wrote:
> Commit 71523d1812ac (pwm: Ensure pwm_apply_state() doesn't modify the
> state argument) updated the kernel-doc for pwm_apply_state(), but not
> for the ->apply callback in the pwm_ops struct.
>
> Signed-off-by: Rasmus Villemoes
>
On Fri, Oct 04, 2019 at 03:32:06PM +0200, Rasmus Villemoes wrote:
> Since the divisor is not a compile-time constant (unless gcc somehow
> decided to unroll the loop PERIOD_CDIV_MAX times), this does a
> somewhat expensive 32/32 division. Replace that with a right shift.
>
> We still have a 64/32
On Tue, 01 Oct 2019, Lukasz Majewski wrote:
> > On Mon, 30 Sep 2019, Lukasz Majewski wrote:
> >
> > > Dear Lee,
> > >
> > > > This patch set provides several enhancements to mc13xxx MFD family
> > > > of devices by introducing mc34708 as a separate device.
> > > >
> > > > This IC has dedicated
On Fri, Oct 4, 2019 at 7:27 AM Yegor Yefremov
wrote:
>
> Hi Adam,
>
> On Fri, Oct 4, 2019 at 12:39 PM Adam Ford wrote:
> >
> > On Fri, Oct 4, 2019 at 5:02 AM Adam Ford wrote:
> > >
> > > I am running Kernel 5.3.2 trying to troubleshoot some intermittent
> > > Bluetooth issues, and I think I have
On 04/10/2019 16.39, Michal Hocko wrote:
On Fri 04-10-19 16:32:39, Konstantin Khlebnikov wrote:
On 04/10/2019 16.12, Michal Hocko wrote:
On Fri 04-10-19 16:09:22, Konstantin Khlebnikov wrote:
This is very slow operation. There is no reason to do it again if somebody
else already drained all pe
>
> On Fri, Oct 4, 2019 at 11:19 AM Mika Westerberg
> wrote:
> >
> > On Fri, Oct 04, 2019 at 11:07:34AM +0300, Yehezkel Bernat wrote:
> > > > Also if you can get the hw_vendor_id and hw_product_id from the kernel
> > > > does that mean you don't need to do the two reads or you still need
> > > >
Hi yannick
On 10/4/19 3:17 PM, Yannick Fertré wrote:
Enable focaltech ft6236 touchscreen on STM32MP157C-DK2 board.
Signed-off-by: Yannick Fertré
---
arch/arm/boot/dts/stm32mp157c-dk2.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts
From: Will Deacon
Closing /dev/pts/ptmx removes the corresponding pty under /dev/pts/
without synchronizing against concurrent path walkers. This can lead to
'dcache_readdir()' tripping over a 'struct dentry' with a NULL 'd_inode'
field:
| BUG: kernel NULL pointer dereference, address: 000
Hello,
syzbot has tested the proposed patch but the reproducer still triggered
crash:
KASAN: use-after-free Read in rxrpc_release_call
==
BUG: KASAN: use-after-free in rxrpc_release_call+0x973/0xaa0
net/rxrpc/call_object.c:498
From: Pavel Begunkov
io_queue_link_head() accepts @force_nonblock flag, but io_ring_submit()
passes something opposite.
v2: build error from test robot: Rebase to block-tree
v3: simplify with Jens suggestion
Reported-by: kbuild test robot
Signed-off-by: Pavel Begunkov
---
fs/io_uring.c | 2 +
Map "xen_nopvspin" to "nopvspin", fix stale description of "xen_nopvspin"
as we use qspinlock now.
Signed-off-by: Zhenzhong Duan
Cc: Jonathan Corbet
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
--
pr_*() is preferred than printk(KERN_* ...), after change all the print
in arch/x86/kernel/kvm.c will have "kvm_guest: xxx" style.
No functional change.
Signed-off-by: Zhenzhong Duan
Cc: Paolo Bonzini
Cc: Radim Krcmar
Cc: Sean Christopherson
Cc: Vitaly Kuznetsov
Cc: Wanpeng Li
Cc: Jim Matts
There are cases where a guest tries to switch spinlocks to bare metal
behavior (e.g. by setting "xen_nopvspin" on XEN platform and
"hv_nopvspin" on HYPER_V).
That feature is missed on KVM, add a new parameter "nopvspin" to disable
PV spinlocks for KVM guest.
The new 'nopvspin' parameter will also
Map "hv_nopvspin" to "nopvspin".
Signed-off-by: Zhenzhong Duan
Cc: Jonathan Corbet
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Sasha Levin
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
---
Documentation/admin-guide/kernel-parameters.
There are cases folks want to disable spinlock optimization for
debug/test purpose. Xen and hyperv already have parameters "xen_nopvspin"
and "hv_nopvspin" to support that, but kvm doesn't.
The first patch adds that feature to KVM guest with "nopvspin".
For compatibility reason original parameter
On Mon, 09 Sep 2019, Lukasz Majewski wrote:
> From: Sascha Hauer
>
> The mc34708 has an improved adc. The older variants will always convert
> a fixed order of channels. The mc34708 can do up to eight conversions
> in arbitrary channel order. Currently this extended feature is not
> supported. W
On Fri, Oct 4, 2019 at 8:23 AM Lucas Stach wrote:
>
> Am Freitag, den 04.10.2019, 10:27 +0100 schrieb Russell King - ARM
> Linux admin:
> > On Thu, Oct 03, 2019 at 02:30:10PM +0300, Mike Rapoport wrote:
> > > On Thu, Oct 03, 2019 at 09:49:14AM +0100, Russell King - ARM Linux
> > > admin wrote:
> >
On Wed, Oct 2, 2019 at 5:45 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:a32db7e1 Add linux-next specific files for 20191002
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=175ab7cd60
> kernel config: https:/
On Fri, 2019-10-04 at 15:38 +0200, Michal Hocko wrote:
> On Fri 04-10-19 09:30:39, Qian Cai wrote:
> > On Fri, 2019-10-04 at 15:07 +0200, Michal Hocko wrote:
> > > On Fri 04-10-19 08:56:16, Qian Cai wrote:
> > > [...]
> > > > It might be a good time to rethink if it is really a good idea to
> > >
On Fri, Oct 4, 2019 at 2:05 PM Walter Wu wrote:
>
> On Fri, 2019-10-04 at 11:54 +0200, Dmitry Vyukov wrote:
> > > > "out-of-bounds" is the _least_ frequent KASAN bug type. So saying
> > > > "out-of-bounds" has downsides of both approaches and won't prevent
> > > > duplicate reports by syzbot...
>
On Mon, 30 Sep 2019, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Convert the binding document for max77650 core mfd module to yaml.
MAX77650, MFD, YAML.
> Signed-off-by: Bartosz Golaszewski
> ---
> .../devicetree/bindings/mfd/max77650.txt | 47 +--
> .../devicetre
The port type macros should have different values for different devices.
Currently, PORT_LINFLEXUART conflicts with PORT_SUNIX.
Fixes: 09864c1cdf5c ("tty: serial: Add linflexuart driver for S32V234")
Signed-off-by: Stefan-Gabriel Mirea
---
include/uapi/linux/serial_core.h | 2 +-
1 file changed,
On 10/4/19 2:08 PM, Mauro Carvalho Chehab wrote:
Em Fri, 4 Oct 2019 13:50:43 +0200
JP escreveu:
On 10/3/19 10:03 PM, Mauro Carvalho Chehab wrote:
Em Thu, 3 Oct 2019 21:51:35 +0200
Gonsolo escreveu:
1) The firmware file is likely at the Windows driver for this device
(probably using a
On Fri, Oct 04, 2019 at 01:15:21PM +0200, Petr Mladek wrote:
> On Fri 2019-10-04 11:49:48, Will Deacon wrote:
> > On Fri, Oct 04, 2019 at 10:29:17AM +0100, Russell King - ARM Linux admin
> > wrote:
> > > On Fri, Oct 04, 2019 at 11:11:42AM +0200, Petr Mladek wrote:
> > > > On Thu 2019-10-03 21:56:3
Denis Efremov wrote:
> The id pointer can be NULL in rsi_probe(). It is checked everywhere except
> for the else branch in the idProduct condition. The patch adds NULL check
> before the id dereference in the rsi_dbg() call.
>
> Fixes: 54fdb318c111 ("rsi: add new device model for 9116")
> Cc: Am
On Fri, Oct 04, 2019 at 12:12:15PM +0200, Pavel Machek wrote:
On Thu 2019-10-03 17:52:36, Greg Kroah-Hartman wrote:
From: A Sun
Other changes:
The driver's write to USB device architecture change (async to sync I/O)
is significant so we bump DRIVER_VERSION to "1.95" (from "1.94").
---
d
Subject: Memo from Orthopaedic Surgeon at Singapore General Hospital for Early
Onset of Osteoarthritis
Singapore General Hospital
SingHealth
2 October 2019
Dear Sir/Madam
TURRITOPSIS DOHRNII TEO EN MING -ZHANG ENMING ,
To Whom It May Concern,
This gent has early osteoarthritis.
He cannot st
Hi Hans,
It seems that there is a bug in the patch. Thank you for catching this!
I will revise the patch and upload it again.
On Thu, Oct 3, 2019 at 6:38 PM Hans de Goede wrote:
>
> Hi,
>
> On 03-10-2019 12:04, Kyle Tso wrote:
> > Hi Hans
> >
> > Could you append the TCPM log?
>
> I've attac
Hi Xiaojun,
I wanted to ask if you are still working on this?
I've noticed that it doesn't apply cleanly to perf/core anymore and I was
working on re-basing it.
Would you be interested in me posting my progress?
I was also interested in decoding the "data source" of events and displaying
that
Colin King wrote:
> From: Colin Ian King
>
> The variable ret is being assigned a value that is never read and is
> being re-assigned a little later on. The assignment is redundant and hence
> can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
> Reviewed-
In case of an error (e.g. memory pool too small), kmemleak disables
itself and cleans up the already allocated metadata objects. However, if
this happens early before the RCU callback mechanism is available,
put_object() skips call_rcu() and frees the object directly. This is not
safe with the RCU
We know the answer, so don't ask the user.
Signed-off-by: Changbin Du
---
arch/x86/mm/extable.c | 5 -
arch/x86/mm/mm_internal.h | 11 +++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c
index 4d75bc656f97..5196e586756
On Fri, Oct 4, 2019 at 6:26 AM Kirill A. Shutemov wrote:
> On Fri, Oct 04, 2019 at 02:33:49PM +0200, Michal Hocko wrote:
> > On Wed 02-10-19 19:08:16, Daniel Colascione wrote:
> > > On Wed, Oct 2, 2019 at 6:56 PM Qian Cai wrote:
> > > > > On Oct 2, 2019, at 4:29 PM, Daniel Colascione
> > > > >
Hi Peter,
On Thu, 3 Oct 2019 13:01:06 +0200
Peter Zijlstra wrote:
> On Thu, Oct 03, 2019 at 10:27:51AM +0200, Peter Zijlstra wrote:
> > On Thu, Oct 03, 2019 at 02:00:50PM +0900, Masami Hiramatsu wrote:
> >
> > > > This fits almost all text_poke_bp() users, except
> > > > arch_unoptimize_kprobe(
The Raspberry Pi 4 SDHCI hardware seems to automatically issue CMD12
after multiblock reads even when ACMD12 is disabled. This triggers
spurious interrupts after the data transfer is done with the following
message:
mmc1: Got data interrupt 0x0002 even though no data operation was in
progre
On Fri, 4 Oct 2019 13:22:37 +0200
Peter Zijlstra wrote:
> On Thu, Oct 03, 2019 at 06:10:45PM -0400, Steven Rostedt wrote:
> > But still, we are going from 120 to 660 IPIs for every CPU. Not saying
> > it's a problem, but something that we should note. Someone (those that
> > don't like kernel int
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
cc9604d48fc3b73d9665ae80a2f07dc3fc0574c4
On Fri, 4 Oct 2019 10:10:47 +0200
Daniel Bristot de Oliveira wrote:
> [ In addition ]
>
> Currently, ftrace_rec entries are ordered inside the group of functions, but
> "groups of function" are not ordered. So, the current int3 handler does a (*):
>
> for_each_group_of_functions:
> check
On Fri 04-10-19 16:32:39, Konstantin Khlebnikov wrote:
> On 04/10/2019 16.12, Michal Hocko wrote:
> > On Fri 04-10-19 16:09:22, Konstantin Khlebnikov wrote:
> > > This is very slow operation. There is no reason to do it again if somebody
> > > else already drained all per-cpu vectors while we waite
Add a driver for managing SRAM device toughether with dedicated file system.
It is a work-in-progress patch which combines driver and file system.
It was used for experiments and proof-of-concept.
It should be split, when I find the proper way to do it.
It also contains debugging prints which shoul
Hi all,
This patch set tries to introduce a direct mapping mechanism of SRAM
memory regions directly into user space.
This is a draft of some reaserch work which I am going to continue.
Since it is my last day in the office I have publish it as a RFC.
Benefits of having SRAM memory in the user sp
Signed-off-by: Lukasz Luba
---
arch/arm/boot/dts/exynos54xx.dtsi | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/exynos54xx.dtsi
b/arch/arm/boot/dts/exynos54xx.dtsi
index 0b27bebf9528..1e43ad9f2d89 100644
--- a/arch/arm/boot/dts/exynos54xx.dtsi
On Fri 04-10-19 09:30:39, Qian Cai wrote:
> On Fri, 2019-10-04 at 15:07 +0200, Michal Hocko wrote:
> > On Fri 04-10-19 08:56:16, Qian Cai wrote:
> > [...]
> > > It might be a good time to rethink if it is really a good idea to
> > > dump_page()
> > > at all inside has_unmovable_pages(). As it is r
Since we now have ->apply, these are no longer relevant.
Signed-off-by: Rasmus Villemoes
---
drivers/pwm/pwm-mxs.c | 77 ---
1 file changed, 77 deletions(-)
diff --git a/drivers/pwm/pwm-mxs.c b/drivers/pwm/pwm-mxs.c
index 10efd3de0bb3..5a6835e18fc6 100644
Wolfram,
Would you be kind enough to grep for your name below?
On Tue, 24 Sep 2019, Gene Chen wrote:
> From: Gene Chen
>
> Add mfd driver for mt6360 pmic chip include
> Battery Charger/USB_PD/Flash LED/RGB LED/LDO/Buck
>
> Signed-off-by: Gene Chen ---
> drivers/mfd/Kconfig|
We need to increase the pwm-cells for the optional flags parameter, in
order to implement support for polarity setting via DT.
Acked-by: Rob Herring
Signed-off-by: Rasmus Villemoes
---
Documentation/devicetree/bindings/pwm/mxs-pwm.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
d
Commit 71523d1812ac (pwm: Ensure pwm_apply_state() doesn't modify the
state argument) updated the kernel-doc for pwm_apply_state(), but not
for the ->apply callback in the pwm_ops struct.
Signed-off-by: Rasmus Villemoes
---
include/linux/pwm.h | 5 +
1 file changed, 1 insertion(+), 4 deletio
Since the divisor is not a compile-time constant (unless gcc somehow
decided to unroll the loop PERIOD_CDIV_MAX times), this does a
somewhat expensive 32/32 division. Replace that with a right shift.
We still have a 64/32 division just below, but at least in that
case the divisor is compile-time c
This series adds support for setting the polarity via DT to the
pwm-mxs driver.
The DT binding is updated, but I'm not touching the existing .dts or
.dtsi files - it seems that the same was done for bcm2835 in commits
46421d9d8e802e570dfa4d793a4938d2642ec7a7 and
8a88b2a2017d1e7e80db53080baff591fd4
In preparation for supporting setting the polarity, switch the driver
to support the ->apply method.
Signed-off-by: Rasmus Villemoes
---
drivers/pwm/pwm-mxs.c | 70 +++
1 file changed, 70 insertions(+)
diff --git a/drivers/pwm/pwm-mxs.c b/drivers/pwm/pwm-
If I'm reading of_pwm_xlate_with_flags() right, existing device trees
that set #pwm-cells = 2 will continue to work.
Signed-off-by: Rasmus Villemoes
---
drivers/pwm/pwm-mxs.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/pwm/pwm-mxs.c b/drivers/pwm/p
On 04/10/2019 16.12, Michal Hocko wrote:
On Fri 04-10-19 16:09:22, Konstantin Khlebnikov wrote:
This is very slow operation. There is no reason to do it again if somebody
else already drained all per-cpu vectors while we waited for lock.
Piggyback on drain started and finished while we waited f
On 10/4/19 5:01 AM, Mika Westerberg wrote:
> On Fri, Oct 04, 2019 at 11:59:26AM +0200, Rafael J. Wysocki wrote:
>> On Friday, October 4, 2019 10:03:40 AM CEST Mika Westerberg wrote:
>>> On Thu, Oct 03, 2019 at 09:50:33AM -0700, Tejun Heo wrote:
Hello, Mika.
On Wed, Oct 02, 2019 at 03
On Fri, 2019-10-04 at 15:07 +0200, Michal Hocko wrote:
> On Fri 04-10-19 08:56:16, Qian Cai wrote:
> [...]
> > It might be a good time to rethink if it is really a good idea to
> > dump_page()
> > at all inside has_unmovable_pages(). As it is right now, it is a a potential
> > deadlock between con
On Fri, Oct 04, 2019 at 02:33:49PM +0200, Michal Hocko wrote:
> On Wed 02-10-19 19:08:16, Daniel Colascione wrote:
> > On Wed, Oct 2, 2019 at 6:56 PM Qian Cai wrote:
> > > > On Oct 2, 2019, at 4:29 PM, Daniel Colascione wrote:
> > > >
> > > > Adding the correct linux-mm address.
> > > >
> > > >
>
On Fri, Oct 04, 2019 at 02:58:59PM +0200, Thomas Hellström (VMware) wrote:
> On 10/4/19 2:37 PM, Kirill A. Shutemov wrote:
> > On Thu, Oct 03, 2019 at 01:32:45PM +0200, Thomas Hellström (VMware) wrote:
> > > > > + * If @mapping allows faulting of huge pmds and puds, it is
> > > > > desirable
> >
Am Freitag, den 04.10.2019, 10:27 +0100 schrieb Russell King - ARM
Linux admin:
> On Thu, Oct 03, 2019 at 02:30:10PM +0300, Mike Rapoport wrote:
> > On Thu, Oct 03, 2019 at 09:49:14AM +0100, Russell King - ARM Linux
> > admin wrote:
> > > On Thu, Oct 03, 2019 at 08:34:52AM +0300, Mike Rapoport wrot
On 10/4/19 4:00 AM, Mika Westerberg wrote:
> A removable block device, such as NVMe or SSD connected over Thunderbolt
> can be hot-removed any time including when the system is suspended. When
> device is hot-removed during suspend and the system gets resumed, kernel
> first resumes devices and the
Hi Linus,
Please pull a few DT fixes for 5.4.
Rob
The following changes since commit 54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c:
Linux 5.4-rc1 (2019-09-30 10:35:40 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
tags/devicetree-fi
Hi Alex,
ok, i'll push only the dt patch link to the last version of driver
touchscreen on display board MB1407.
BR
Yannick Fertré
On 10/3/19 12:34 PM, Alexandre Torgue wrote:
> Hi Yannick
>
> On 9/30/19 4:45 PM, Yannick Fertré wrote:
>> Enable focaltech ft6236 touchscreen on STM32MP157C-DK2
Enable focaltech ft6236 touchscreen on STM32MP157C-DK2 board.
Signed-off-by: Yannick Fertré
---
arch/arm/boot/dts/stm32mp157c-dk2.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts
b/arch/arm/boot/dts/stm32mp157c-dk2.dts
index 20ea601..d
On Fri, Oct 04, 2019 at 03:00:31PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Oct 03, 2019 at 11:29:11AM +0200, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > Some time ago I started a discussion about the need for a proper early
> > device
> > probing mechanism[1]. One that wo
On Wed, Oct 02, 2019 at 02:59:58AM +0300, Tomas Winkler wrote:
> From: Alexander Usyskin
>
> The fixed MKHI client on PCH 6 gen platforms
> does not support fw version retrieval.
> The error is not fatal, but it fills up the kernel logs and
> slows down the driver start.
> This patch disables req
Using bool on struct is not recommended, as it wastes lots of
space. So, instead, let's use bits.
While here, convert the comments to kernel-doc format.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-frontends/si2168.h | 47 +--
drivers/media/dvb-frontends/s
Some devices (Logilink VG0022A) don't work properly with the
standard firmware. Upgrading the firmware makes I2C transfers
to fail when talking to the tuner.
While we don't have a better alternative, add support to
disable the firmware load on such devices.
Signed-off-by: Mauro Carvalho Chehab
-
A very old patch sent to the media ML used to contain the
I2C speed formula:
https://lore.kernel.org/linux-media/1312539895.2763.33.camel@Jason-Linux/
When the ite9135 code was merged with af9035, the formula was
lost. As we might need to slow down the speed for some devices,
add the for
This it930x-based device has an issue with si2068.
When the si2168 firmware that came with the device is replaced
by a new one, any I2C data received from the tuner will be
replaced by 0xff.
Probably, the vendor firmware has some patch specifically
designed for this device. So, we can't replace b
On Thu, Oct 03, 2019 at 07:05:56PM -0700 Xuewei Zhang wrote:
> +cc neeln...@google.com and hao...@google.com, they helped a lot
> for this issue. Sorry I forgot to include them when sending out the patch.
>
> On Thu, Oct 3, 2019 at 5:55 PM Phil Auld wrote:
> >
> > Hi,
> >
> > On Thu, Oct 03, 2019
On Fri 04-10-19 16:09:22, Konstantin Khlebnikov wrote:
> This is very slow operation. There is no reason to do it again if somebody
> else already drained all per-cpu vectors while we waited for lock.
>
> Piggyback on drain started and finished while we waited for lock:
> all pages pended at the t
On Fri, Sep 20, 2019 at 04:57:26PM +0800, Qiujun Huang wrote:
> vt_console_print could trigger NMI watchdog in case writing slow:
>
> [2858736.789664] NMI watchdog: Watchdog detected hard LOCKUP on cpu 23
> ...
> [2858736.790194] CPU: 23 PID: 32504 Comm: tensorflow_mode Not tainted
> 4.4.131-1.el
On 10/4/19 1:35 AM, Fabrizio Castro wrote:
RZ/G2N (a.k.a. R8A774B1) watchdog implementation is compatible
with R-Car Gen3, therefore add the relevant documentation.
Signed-off-by: Fabrizio Castro
Reviewed-by: Guenter Roeck
---
Documentation/devicetree/bindings/watchdog/renesas,wdt.txt |
This is very slow operation. There is no reason to do it again if somebody
else already drained all per-cpu vectors while we waited for lock.
Piggyback on drain started and finished while we waited for lock:
all pages pended at the time of our enter were drained from vectors.
Callers like POSIX_F
On Thu, Oct 03, 2019 at 03:19:46PM +0300, mika.westerb...@linux.intel.com wrote:
> On Fri, Jul 26, 2019 at 12:52:58PM +, Nicholas Johnson wrote:
> > Patch series rebased to 5.3-rc1.
> >
> > If possible, please have a quick read over while I am away (2019-07-27
> > to mid 2019-08-04), so I can
Am 04.10.19 um 14:59 schrieb Nicolas Saenz Julienne:
> On Fri, 2019-10-04 at 14:52 +0200, Nicolas Saenz Julienne wrote:
>> The Raspberry Pi 4 SDHCI hardware seems to automatically issue CMD12
>> after multiblock reads even when ACMD12 is disabled. This triggers
>> spurious interrupts after the data
On Fri 04-10-19 08:56:16, Qian Cai wrote:
[...]
> It might be a good time to rethink if it is really a good idea to dump_page()
> at all inside has_unmovable_pages(). As it is right now, it is a a potential
> deadlock between console vs memory offline. More details are in this thread,
>
> https://
On Fri, Oct 04, 2019 at 02:57:21PM +0200, Matthias Andree wrote:
> Am 04.10.19 um 14:39 schrieb Mika Westerberg:
> > @Matthias, @Paul and @Nicholas, I appreciate if you could check that this
> > does not cause any issues for your systems.
>
> Just to be sure: is this intended to be applied against
On 04. 10. 19 14:52, Greg Kroah-Hartman wrote:
> On Fri, Sep 13, 2019 at 09:28:29AM +0200, Michal Simek wrote:
>> There are two parts which should be fixed. The first one is to assigned
>> uartps_major at the end of probe() to avoid complicated logic when
>> something fails.
>> The second part is i
There are two parts which should be fixed. The first one is to assigned
uartps_major at the end of probe() to avoid complicated logic when
something fails.
The second part is initialized uartps_major number to 0 when last device is
removed. This will ensure that on next probe driver will ask for ne
501 - 600 of 841 matches
Mail list logo