On Tue, 2019-09-17 at 15:13 -0500, Rob Herring wrote:
> On Tue, Sep 10, 2019 at 1:21 AM Philippe Schenker
> wrote:
> > This adds the documentation to the compatible regulator-fixed-clock.
> > This binding is a special binding of regulator-fixed and adds the
> > ability to add a clock to regulator-
There is little reason for the from/to logic, printing a subset of
the bits can be done by simply shifting/masking value if needed.
Also use for_each_set_bit().
Suggested-by: Jani Nikula
Signed-off-by: Gerd Hoffmann
Reviewed-by: Jani Nikula
---
include/drm/drm_print.h | 5 ++---
Hi Krzysztof,
On 21.09.2019 19:01, Krzysztof Kozlowski wrote:
> Multi Core Timer node has interrupts routed to two different parents -
> GIC and combiner. This was modeled with a interrupt-map within a
> subnode but can be expressed in an easier and more common way, directly
> in the node itself.
On 04.09.19 18:15, Anup Patel wrote:
We get illegal instruction trap whenever Guest/VM executes WFI
instruction.
This patch handles WFI trap by blocking the trapped VCPU using
kvm_vcpu_block() API. The blocked VCPU will be automatically
resumed whenever a VCPU interrupt is injected from user-s
On 04.09.19 18:15, Anup Patel wrote:
We will get stage2 page faults whenever Guest/VM access SW emulated
MMIO device or unmapped Guest RAM.
This patch implements MMIO read/write emulation by extracting MMIO
details from the trapped load/store instruction and forwarding the
MMIO read/write to u
On 04.09.19 18:14, Anup Patel wrote:
This patch implements VCPU create, init and destroy functions
required by generic KVM module. We don't have much dynamic
resources in struct kvm_vcpu_arch so thest functions are quite
Since you're respinning for v8 anyway, please s/thest/these/ :)
Alex
On 20/09/19 5:53 PM, Thierry Reding wrote:
> From: Nicolin Chen
>
> The SDHCI controller on Tegra186 supports 40-bit addressing, which is
> usually enough to address all of system memory. However, if the SDHCI
> controller is behind an IOMMU, the address space can go beyond. This
> happens on Teg
On 20/09/19 5:53 PM, Thierry Reding wrote:
> From: Nicolin Chen
>
> The SDHCI controller on Tegra186 supports 40-bit addressing, which is
> usually enough to address all of system memory. However, if the SDHCI
> controller is behind an IOMMU, the address space can go beyond. This
> happens on Teg
From: Peng Fan
This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous recei
From: Peng Fan
The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.
Signed-off
From: Peng Fan
V7:
Typo fix
#mbox-cells changed to 0
Add a new header file arm-smccc-mbox.h
Use ARM_SMCCC_IS_64
Andre,
The function_id is still kept in arm_smccc_mbox_cmd, because arm,func-id
property is optional, so clients could pass function_id to mbox driver.
V6:
Switch to per-channel a m
Hi Matthias,
Thank you for your review.
On 9/18/2019 11:22 PM, Matthias Kaehlcke wrote:
Hi Taniya,
not a full review, just a couple of things I noticed, comments inline.
On Wed, Sep 18, 2019 at 03:20:17PM +0530, Taniya Das wrote:
The GCC clock provider have a bunch of generic properties that
There's a bug in skiboot that causes the OPAL_XIVE_ALLOCATE_IRQ call
to return the 32-bit value 0x when OPAL has run out of IRQs.
Unfortunatelty, OPAL return values are signed 64-bit entities and
errors are supposed to be negative. If that happens, the linux code
confusingly treats 0xff
On 09/21/2019 09:30 PM, kbuild test robot wrote:
> Hi Anshuman,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [cannot apply to v5.3 next-20190919]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve t
I hit the following error when compile the kernel.
drivers/firmware/broadcom/bcm47xx_nvram.c: In function ‘nvram_init’:
./include/linux/kern_levels.h:5:18: warning: format ‘%zu’ expects argument of
type ‘size_t’, but argument 2 has type ‘u32 {aka unsigned int}’ [-Wformat=]
#define KERN_SOH "\001
Normally when creation of workqueue fails, exception handling takes place
after the call to alloc_workqueue() is made.
But looking into usb_hub_init() function, 'return 0' statement is executed,
when alloc_workqueue() returns valid workqueue pointer.
if (hub_wq)
return 0;
Th
Hello Jakub,
On 9/22/19 5:06 AM, Jakub Kicinski wrote:
> On Fri, 20 Sep 2019 15:31:15 +0200, Uwe Kleine-König wrote:
>> According to Tal Gilboa the only benefit from DIM comes from a driver
>> that uses it. So it doesn't make sense to make this symbol user visible,
>> instead all drivers that use
Hi Benoit,
On Fri, Sep 20, 2019 at 11:55:29AM -0500, Benoit Parrot wrote:
...
> > > @@ -1400,6 +1440,18 @@ static int ov2659_probe(struct i2c_client *client)
> > > ov2659->xvclk_frequency > 2700)
> > > return -EINVAL;
> > >
> > > + /* Optional gpio don't fail if not present *
Fix sparse warning:
drivers/net/ethernet/freescale/gianfar.c:2070:6:
warning: symbol 'reset_gfar' was not declared. Should it be static?
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/net/ethernet/freescale/gianfar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
drivers/md/dm-clone-target.c:594:34: warning:
symbol '__hash_find' was not declared. Should it be static?
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/md/dm-clone-target.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/md/dm-clone-target.c b/d
On 2019-09-21 03:50, Stephen Boyd wrote:
Quoting Lina Iyer (2019-09-17 14:50:20)
On Fri, Sep 13 2019 at 13:53 -0600, Lina Iyer wrote:
>On Thu, Sep 05 2019 at 18:03 -0600, Stephen Boyd wrote:
>>Quoting Lina Iyer (2019-09-03 10:07:22)
>>>On Mon, Sep 02 2019 at 07:58 -0600, Marc Zyngier wrote:
Hi Ayman,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on next-20190918]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch,
Fix sparse warning:
fs/nfsd/nfssvc.c:364:6: warning:
symbol 'nfsd_reset_boot_verifier_locked' was not declared. Should it be static?
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
fs/nfsd/nfssvc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/nfsd/nfssvc.c b/fs
Couple of users had requested to print the SCSI command age along
with command failure errors. This is a small change, but allows
users to get more important information about the command that was
failed, it would help the users in debugging the command failures:
Signed-off-by: Milan P. Gandhi
On Fri, Sep 20, 2019 at 09:16:12AM -0700, Dave Hansen wrote:
>On 9/19/19 7:18 PM, Wei Yang wrote:
>> Last but not least, since update_mmu_cache_pmd is empty, even return
>> value is not correct, it doesn't break anything.
>
>In other words, this patch has no functional effect and does not provide
>
Fix sparse warning:
fs/fuse/dev.c:468:6: warning: symbol 'fuse_args_to_req' was not declared.
Should it be static?
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
fs/fuse/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 46d68d
On 09/16/2019 11:17 AM, Anshuman Khandual wrote:
> In add_memory_resource() the memory range to be hot added first gets into
> the memblock via memblock_add() before arch_add_memory() is called on it.
> Reverse sequence should be followed during memory hot removal which already
> is being follow
This adds ext4_ilock/iunlock types of APIs.
This is the preparation APIs to make shared
locking/unlocking & restarting with exclusive
locking/unlocking easier in next patch.
Along with above this also addresses the AIM7
regression problem which was only fixed for XFS
in,
commit 942491c9e6d6 ("xfs:
Hello All,
These are ilock patches which helps improve the current inode lock scalabiliy
problem in ext4 DIO mixed-read/write workload case. The problem was first
reported by Joseph [1]. These patches are based upon upstream discussion
with Jan Kara & Joseph [2].
Since these patches introduce e
Earlier there was no shared lock in DIO read path.
But this patch (16c54688592ce: ext4: Allow parallel DIO reads)
simplified some of the locking mechanism while still allowing
for parallel DIO reads by adding shared lock in inode DIO
read path.
But this created problem with mixed read/write worklo
This series enables memory hot remove on arm64 after fixing a possible arm64
platform specific kernel page table race condition. This series is based on
linux-next (next-20190920).
Concurrent vmalloc() and hot-remove conflict:
As pointed out earlier on the v5 thread [2] there can be potential con
The arch code for hot-remove must tear down portions of the linear map and
vmemmap corresponding to memory being removed. In both cases the page
tables mapping these regions must be freed, and when sparse vmemmap is in
use the memory backing the vmemmap must also be freed.
This patch adds unmap_ho
The arm64 page table dump code can race with concurrent modification of the
kernel page tables. When a leaf entries are modified concurrently, the dump
code may log stale or inconsistent information for a VA range, but this is
otherwise not harmful.
When intermediate levels of table are freed, the
Fix sparse warnings:
drivers/scsi/hisi_sas/hisi_sas_main.c:3686:6:
warning: symbol 'hisi_sas_debugfs_release' was not declared. Should it be
static?
drivers/scsi/hisi_sas/hisi_sas_main.c:3708:5:
warning: symbol 'hisi_sas_debugfs_alloc' was not declared. Should it be static?
drivers/scsi/hisi_sa
On Mon, Aug 12, 2019 at 05:31:33PM +0300, Mika Westerberg wrote:
> If there are more than one PCIe switch with hotplug downstream ports
> hot-removing them leads to a following deadlock:
For the record, I think my comments on v1 of this patch still apply:
https://patchwork.ozlabs.org/patch/111787
Hi zhong,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190920]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
b
On 2019/9/23 上午11:18, Matt Cover wrote:
On Sun, Sep 22, 2019 at 7:34 PM Jason Wang wrote:
On 2019/9/23 上午9:15, Matt Cover wrote:
On Sun, Sep 22, 2019 at 5:51 PM Jason Wang wrote:
On 2019/9/23 上午6:30, Matt Cover wrote:
On Sun, Sep 22, 2019 at 1:36 PM Michael S. Tsirkin wrote:
On Sun, Se
On 2019/9/23 上午11:00, Matt Cover wrote:
On Sun, Sep 22, 2019 at 7:32 PM Jason Wang wrote:
On 2019/9/23 上午9:20, Matt Cover wrote:
On Sun, Sep 22, 2019 at 5:46 PM Jason Wang wrote:
On 2019/9/23 上午1:43, Matt Cover wrote:
On Sun, Sep 22, 2019 at 5:37 AM Michael S. Tsirkin wrote:
On Fri, Se
Hi Paolo, Marc
> -Original Message-
> From: Paolo Bonzini
> Sent: Thursday, September 19, 2019 7:07 PM
> To: Jianyong Wu (Arm Technology China) ;
> net...@vger.kernel.org; yangbo...@nxp.com; john.stu...@linaro.org;
> t...@linutronix.de; sean.j.christopher...@intel.com; m...@kernel.org;
>
On Fri, Sep 20, 2019 at 04:54:21PM +0100, Will Deacon wrote:
> Hi Marco,
>
> On Fri, Sep 20, 2019 at 04:18:57PM +0200, Marco Elver wrote:
> > We would like to share a new data-race detector for the Linux kernel:
> > Kernel Concurrency Sanitizer (KCSAN) --
> > https://github.com/google/ktsan/wiki/K
The existing gup code does not react to the fatal signals in many code
paths. For example, in one retry path of gup we're still using
down_read() rather than down_read_killable(). Also, when doing page
faults we don't pass in FAULT_FLAG_KILLABLE as well, which means that
within the faulting proce
The idea comes from a discussion between Linus and Andrea [1].
Before this patch we only allow a page fault to retry once. We
achieved this by clearing the FAULT_FLAG_ALLOW_RETRY flag when doing
handle_mm_fault() the second time. This was majorly used to avoid
unexpected starvation of the system
This is the gup counterpart of the change that allows the
VM_FAULT_RETRY to happen for more than once. One thing to mention is
that we must check the fatal signal here before retry because the GUP
can be interrupted by that, otherwise we can loop forever.
Signed-off-by: Peter Xu
---
mm/gup.c
Userfaultfd fault path was by default killable even if the caller does
not have FAULT_FLAG_KILLABLE. That makes sense before in that when
with gup we don't have FAULT_FLAG_KILLABLE properly set before. Now
after previous patch we've got FAULT_FLAG_KILLABLE applied even for
gup code so it should a
The idea comes from the upstream discussion between Linus and Andrea:
https://lore.kernel.org/lkml/20171102193644.gb22...@redhat.com/
A summary to the issue: there was a special path in handle_userfault()
in the past that we'll return a VM_FAULT_NOPAGE when we detected
non-fatal signals when wa
This patch removes the risk path in handle_userfault() then we will be
sure that the callers of handle_mm_fault() will know that the VMAs
might have changed. Meanwhile with previous patch we don't lose
responsiveness as well since the core mm code now can handle the
nonfatal userspace signals even
There's plenty of places around __get_user_pages() that has a parameter
"nonblocking" which does not really mean that "it won't block" (because
it can really block) but instead it shows whether the mmap_sem is
released by up_read() during the page fault handling mostly when
VM_FAULT_RETRY is return
When follow_hugetlb_page() returns with *locked==0, it means we've got
a VM_FAULT_RETRY within the fauling process and we've released the
mmap_sem. When that happens, we should stop and bail out.
Signed-off-by: Peter Xu
---
mm/gup.c | 10 ++
1 file changed, 10 insertions(+)
diff --git
This is the 4th version of the PF enhancement series on signal
handlings and fault retries. This new version does not change
existing patches in v3 but added two more patches to address the
current gup issue on not responding to SIGKILL. A 3rd new patch is
also added to allow handle_userfaultfd t
handle_userfaultfd() is currently the only one place in the kernel
page fault procedures that can respond to non-fatal userspace signals.
It was trying to detect such an allowance by checking against USER &
KILLABLE flags, which was "un-official".
In this patch, we introduced a new flag (FAULT_FLA
Although there're tons of arch-specific page fault handlers, most of
them are still sharing the same initial value of the page fault flags.
Say, merely all of the page fault handlers would allow the fault to be
retried, and they also allow the fault to respond to SIGKILL.
Let's define a default va
On Sat, 21 Sep 2019, Xiaoming Ni wrote:
> @ Nicolas Pitre
> Can I make a v2 patch based on your advice ?
> Or you will submit a patch for "GFP_WONTFAIL" yourself ?
Here's a patch implementing what I had in mind. This is compile tested
only.
- >8
Subject: [PATCH] mm: add __GFP_WONTFAIL and
On Wed, Sep 4, 2019 at 9:44 PM Anup Patel wrote:
>
> For KVM RISC-V, we use KVM_GET_ONE_REG/KVM_SET_ONE_REG ioctls to access
> VCPU config and registers from user-space.
>
> We have three types of VCPU registers:
> 1. CONFIG - these are VCPU config and capabilities
> 2. CORE - these are VCPU gen
On Sat, Sep 21, 2019 at 3:31 PM Paul Walmsley wrote:
>
> Hi Anup,
>
> Thanks for changing this to use a bitmap. A few comments below -
>
> On Wed, 4 Sep 2019, Anup Patel wrote:
>
> > This patch adds riscv_isa bitmap which represents Host ISA features
> > common across all Host CPUs. The riscv_isa
Hi Mika,
On 13/9/2019 4:18 PM, Mika Westerberg wrote:
> On Thu, Sep 12, 2019 at 11:11:32AM +0100, Linus Walleij wrote:
>> Hi Rahul,
>>
>> thanks for your patches!
>>
>> On Thu, Sep 12, 2019 at 8:59 AM Rahul Tanwar
>> wrote:
>>
>>> This series is to add pinctrl & GPIO controller driver for a new
This is the third version of this patch. The first and second version
is in [1] and [2].
This verion is updated according to the comments from Randy Dunlap
in [3].
Currently, I use a VM that has 2 CPUs, 4G memory and 4G swap file.
I found that swap will affect the IO performance when it is runnin
On Sat, 2019-09-21 at 02:21 +0200, Thierry Reding wrote:
> On Fri, Sep 20, 2019 at 06:49:07AM +0800, Sam Shih wrote:
> > From: Ryder Lee
> >
> > This adds a property "num-pwms" in example so that we could
> > specify the number of PWM channels via device tree.
> >
> > Signed-off-by: Ryder Lee
>
I hit the following error when compile the kernel.
security/smack/smack_lsm.c: In function smack_post_notification:
security/smack/smack_lsm.c:4383:7: error: dereferencing pointer to incomplete
type struct watch_notification
if (n->type == WATCH_TYPE_META)
^~
security/smack/smack_lsm.c:4
Hi Marc, Paolo,
> -Original Message-
> From: Paolo Bonzini
> Sent: Thursday, September 19, 2019 8:13 PM
> To: Marc Zyngier ; Jianyong Wu (Arm Technology China)
> ; net...@vger.kernel.org; yangbo...@nxp.com;
> john.stu...@linaro.org; t...@linutronix.de; sean.j.christopher...@intel.com;
> r
On Sun, Sep 22, 2019 at 7:34 PM Jason Wang wrote:
>
>
> On 2019/9/23 上午9:15, Matt Cover wrote:
> > On Sun, Sep 22, 2019 at 5:51 PM Jason Wang wrote:
> >>
> >> On 2019/9/23 上午6:30, Matt Cover wrote:
> >>> On Sun, Sep 22, 2019 at 1:36 PM Michael S. Tsirkin
> >>> wrote:
> On Sun, Sep 22, 2019
I use model checker find a issue of robust and pi futex. On below
situation, the owner can't find something in pi_state_list, while
the requester will be blocked, never be awaked.
CPU0 CPU1
futex_lock_pi
/*some cs code*/
f
On Sun, Sep 22, 2019 at 7:32 PM Jason Wang wrote:
>
>
> On 2019/9/23 上午9:20, Matt Cover wrote:
> > On Sun, Sep 22, 2019 at 5:46 PM Jason Wang wrote:
> >>
> >> On 2019/9/23 上午1:43, Matt Cover wrote:
> >>> On Sun, Sep 22, 2019 at 5:37 AM Michael S. Tsirkin
> >>> wrote:
> On Fri, Sep 20, 2019
Hi, Pavel
> Subject: Re: [PATCH V4 2/5] input: keyboard: imx_sc: Add i.MX system
> controller key support
>
> Hi!
>
> > > > + ret = imx_scu_call_rpc(priv->key_ipc_handle, &msg, true);
> > > > + if (ret) {
> > > > + dev_err(&input->dev, "read imx sc key failed, ret
> >
On 2019/9/23 上午9:15, Matt Cover wrote:
On Sun, Sep 22, 2019 at 5:51 PM Jason Wang wrote:
On 2019/9/23 上午6:30, Matt Cover wrote:
On Sun, Sep 22, 2019 at 1:36 PM Michael S. Tsirkin wrote:
On Sun, Sep 22, 2019 at 10:43:19AM -0700, Matt Cover wrote:
On Sun, Sep 22, 2019 at 5:37 AM Michael S.
Hi, Pavel
> Subject: Re: [PATCH V2 1/5] dt-bindings: fsl: scu: add scu power key binding
>
> On Tue 2019-09-03 10:03:40, Anson Huang wrote:
> > NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as system
> > controller, the system controller is in charge of system power, clock
> > and pow
> Subject: Re: [PATCH] ARM: Add support for Realtek SOC
>
> On Wed, Sep 11, 2019 at 5:17 PM Arnd Bergmann wrote:
> >
> > On Wed, Sep 11, 2019 at 9:46 AM James Tai[戴志峰]
> wrote:
> > > > Subject: Re: [PATCH] ARM: Add support for Realtek SOC
> >
> > > > > @@ -148,6 +148,7 @@ endif
> > > > > textof
On 2019/9/23 上午9:20, Matt Cover wrote:
On Sun, Sep 22, 2019 at 5:46 PM Jason Wang wrote:
On 2019/9/23 上午1:43, Matt Cover wrote:
On Sun, Sep 22, 2019 at 5:37 AM Michael S. Tsirkin wrote:
On Fri, Sep 20, 2019 at 11:58:43AM -0700, Matthew Cover wrote:
Treat a negative return from a TUNSETST
Hi, Pavel
> Subject: Re: [PATCH V2 1/5] dt-bindings: fsl: scu: add scu power key binding
>
> Hi!
>
> > NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as system
> > controller, the system controller is in charge of system power, clock
> > and power key event etc. management, Linux kern
> wrote:
> > > Subject: Re: [PATCH] ARM: Add support for Realtek SOC
>
> > > > @@ -148,6 +148,7 @@ endif
> > > > textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
> > > > textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
> > > > textofs-$(CONFIG_ARCH_MESON) := 0x00208000
> > > > +textofs-$(CONFIG_ARCH_R
Hi Alexandre,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190920]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify t
The Fintek F81532A/534A/535/536 is USB-to-2/4/8/12 serial ports device
and the serial port is default disabled when plugin computer.
The IC is contains devices as following:
1. HUB (all devices is connected with this hub)
2. GPIO/Control device. (enable serial port and control GPIO
The Fintek F81534A series contains 3 GPIOs per UART and The max GPIOs
is 12x3 = 36 GPIOs and this patch will implements GPIO device as a
gpiochip to control all GPIO pins even transforms to transceiver pins.
Signed-off-by: Ji-Ze Hong (Peter Hong)
---
drivers/usb/serial/f81232.c | 249 +++
Use devm_kzalloc() to replace kzalloc().
Signed-off-by: Ji-Ze Hong (Peter Hong)
---
drivers/usb/serial/f81232.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index b42b3738a768..e4db0aec9af0 100644
---
Extract LSR handler to function.
Signed-off-by: Ji-Ze Hong (Peter Hong)
---
drivers/usb/serial/f81232.c | 53 +
1 file changed, 30 insertions(+), 23 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 43fa1f0716b7..c07d37
The Fintek F81532A/534A/535/536 is USB-to-2/4/8/12 serial ports device
and the serial port is default disabled when plugin computer.
The part number is a bit same with F81532/534, but F81534A series UART
core is enhanced from F81232, not F81532/534.
The IC is contains devices as following:
The Fintek F81534A series is contains 1 HUB / 1 GPIO device / n UARTs,
but the UART is default disable and need enabled by GPIO device(2c42/16F8).
When F81534A plug to host, we can only see 1 HUB & 1 GPIO device and we
need write 0x8fff to GPIO device register F81534A_CMD_ENABLE_PORT(116h)
to enab
The Fintek F81532A/534A/535/536 is USB-to-2/4/8/12 serial ports device
and the serial ports are default disabled. Each port contains max 3 pins
GPIO and the 3 pins are default pull high with input mode.
When the serial port had activated (running probe()), we'll transform the
3 pins from GPIO func
Add tx_empty() function for F81232.
Signed-off-by: Ji-Ze Hong (Peter Hong)
---
drivers/usb/serial/f81232.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index c07d376c743d..b42b3738a768 100644
--- a/drivers/usb/s
I hit the following error when compile the kernel.
drivers/iio/light/noa1305.o: In function `noa1305_probe':
noa1305.c:(.text+0x65): undefined reference to `__devm_regmap_init_i2c'
make: *** [vmlinux] Error 1
Signed-off-by: zhong jiang
---
drivers/iio/light/Kconfig | 1 +
1 file changed, 1 inse
On 22/09/2019 04:46, Pavel Machek wrote:
Hi!
Currently the driver does not handle EPROBE_DEFER for the confd gpio.
Use devm_gpiod_get_optional() instead of devm_gpiod_get() and return
error codes from altera_ps_probe().
@@ -265,10 +265,13 @@ static int altera_ps_probe(struct spi_device *spi)
On Sun, Sep 22, 2019 at 5:46 PM Jason Wang wrote:
>
>
> On 2019/9/23 上午1:43, Matt Cover wrote:
> > On Sun, Sep 22, 2019 at 5:37 AM Michael S. Tsirkin wrote:
> >> On Fri, Sep 20, 2019 at 11:58:43AM -0700, Matthew Cover wrote:
> >>> Treat a negative return from a TUNSETSTEERINGEBPF bpf prog as a si
Hi Srinivas,
> >> Subject: [PATCH 2/2] nvmem: imx: scu: support write
> >
> > Ping..
> >
> Thanks for your patience!
> I normally do not take patches after rc5 for nvmem.
> These will be applied after rc1 is released!
Sorry to ping again. Will you pick up since merge window is open?
Thanks,
Peng
On Sun, Sep 22, 2019 at 5:51 PM Jason Wang wrote:
>
>
> On 2019/9/23 上午6:30, Matt Cover wrote:
> > On Sun, Sep 22, 2019 at 1:36 PM Michael S. Tsirkin wrote:
> >> On Sun, Sep 22, 2019 at 10:43:19AM -0700, Matt Cover wrote:
> >>> On Sun, Sep 22, 2019 at 5:37 AM Michael S. Tsirkin
> >>> wrote:
> >
From: Randy Dunlap
Move the AM654 and J721E SOC config options inside the "TI SOC drivers"
menu with the other TI SOC drivers.
Fixes: a869b7b30dac ("soc: ti: Add Support for AM654 SoC config option")
Fixes: cff377f7897a ("soc: ti: Add Support for J721E SoC config option")
Signed-off-by: Randy Du
On 2019/9/23 上午6:30, Matt Cover wrote:
On Sun, Sep 22, 2019 at 1:36 PM Michael S. Tsirkin wrote:
On Sun, Sep 22, 2019 at 10:43:19AM -0700, Matt Cover wrote:
On Sun, Sep 22, 2019 at 5:37 AM Michael S. Tsirkin wrote:
On Fri, Sep 20, 2019 at 11:58:43AM -0700, Matthew Cover wrote:
Treat a neg
When the CONFIG_GENERIC_BUG is disabled by disabling CONFIG_BUG, if a
kernel thread is trapped by BUG(), the whole system will be in the
loop that infinitely handles the ebreak exception instead of entering the
die function. To fix this problem, the do_trap_break() will always call
the die() to dea
The following three situations may occur in the current implementation of
do_trap_break().
1. When the CONFIG_GENERIC_BUG is disabled, if a kernel thread is trapped
by BUG(), the whole system will be in the loop that infinitely handles
the break exception instead of entering the die functio
On RISC-V, when the kernel runs code on behalf of a user thread, and the
kernel executes a WARN() or WARN_ON(), the user thread will be sent
a bogus SIGTRAP. Fix the RISC-V kernel code to not send a SIGTRAP when
a WARN()/WARN_ON() is executed.
Signed-off-by: Vincent Chen
---
arch/riscv/kernel/t
On 2019/9/23 上午1:43, Matt Cover wrote:
On Sun, Sep 22, 2019 at 5:37 AM Michael S. Tsirkin wrote:
On Fri, Sep 20, 2019 at 11:58:43AM -0700, Matthew Cover wrote:
Treat a negative return from a TUNSETSTEERINGEBPF bpf prog as a signal
to fallback to tun_automq_select_queue() for tx queue selecti
To make the code more straightforward, replacing the switch statement
with if statement.
Suggested-by: Paul Walmsley
Signed-off-by: Vincent Chen
---
arch/riscv/kernel/traps.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/arch/riscv/kernel/traps.c
For the kernel space, all ebreak instructions are determined at compile
time because the kernel space debugging module is currently unsupported.
Hence, it should be treated as a bug if an ebreak instruction which does
not belong to BUG_TRAP_TYPE_WARN or BUG_TRAP_TYPE_BUG is executed in
kernel space
FYI, we noticed the following commit (built with gcc-7):
commit: c5e1edaa1a52581b350315e4b163cdcc0fd7605d ("[PATCH v5 7/7] mm,
slab_common: Modify kmalloc_caches[type][idx] to kmalloc_caches[idx][type]")
url:
https://github.com/0day-ci/linux/commits/Pengfei-Li/mm-slab-Make-kmalloc_info-contain-a
On Sun, Sep 22, 2019 at 3:46 PM Matt Cover wrote:
>
> On Sun, Sep 22, 2019 at 3:30 PM Matt Cover wrote:
> >
> > On Sun, Sep 22, 2019 at 1:36 PM Michael S. Tsirkin wrote:
> > >
> > > On Sun, Sep 22, 2019 at 10:43:19AM -0700, Matt Cover wrote:
> > > > On Sun, Sep 22, 2019 at 5:37 AM Michael S. Tsi
On 9/21/19 1:46 PM, Randy Dunlap wrote:
Hi Santosh,
Would you also pick up patch 2/2, which I didn't Cc: you on?:(
Do I need to resend it?
Yes please. I don't have your 2/2
On Sun, Sep 22, 2019 at 3:30 PM Matt Cover wrote:
>
> On Sun, Sep 22, 2019 at 1:36 PM Michael S. Tsirkin wrote:
> >
> > On Sun, Sep 22, 2019 at 10:43:19AM -0700, Matt Cover wrote:
> > > On Sun, Sep 22, 2019 at 5:37 AM Michael S. Tsirkin
> > > wrote:
> > > >
> > > > On Fri, Sep 20, 2019 at 11:58
04.08.2019 23:29, Dmitry Osipenko пишет:
> It is possible to get a lockup if kernel decides to enter LP2 cpuidle
> from some clk-notifier, in that case CCF's "prepare" mutex is kept locked
> and thus clk_get_rate(pclk) blocks on the same mutex with interrupts being
> disabled.
>
> Signed-off-by: D
23.07.2019 5:52, Dmitry Osipenko пишет:
> Unset "enable" bit means that divider is in bypass mode, hence it doesn't
> have any effect in that case. Please note that there are no known bugs
> caused by the missing check.
>
> Signed-off-by: Dmitry Osipenko
> ---
>
> Changelog:
>
> v2: Changed the
Michal Hocko writes:
> From 711000fdc243b6bc68a92f9ef0017ae495086d39 Mon Sep 17 00:00:00 2001
> From: Michal Hocko
> Date: Sun, 22 Sep 2019 08:45:28 +0200
> Subject: [PATCH] kernel/sysctl.c: do not override max_threads provided by
> userspace
>
> Partially revert 16db3d3f1170 ("kernel/sysctl.c:
Heinrich Schuchardt writes:
> Did this patch when applied to the customer's kernel solve any problem?
>
> WebSphere MQ is a messaging application. If it hits the current limits
> of threads-max, there is a bug in the software or in the way that it has
> been set up at the customer. Instead of mes
On Sun, Sep 22, 2019 at 1:36 PM Michael S. Tsirkin wrote:
>
> On Sun, Sep 22, 2019 at 10:43:19AM -0700, Matt Cover wrote:
> > On Sun, Sep 22, 2019 at 5:37 AM Michael S. Tsirkin wrote:
> > >
> > > On Fri, Sep 20, 2019 at 11:58:43AM -0700, Matthew Cover wrote:
> > > > Treat a negative return from a
1 - 100 of 921 matches
Mail list logo
