On 2020/12/10 19:34, Mel Gorman wrote:
> On Thu, Dec 10, 2020 at 04:23:47PM +0800, Li, Aubrey wrote:
>>> I ran this patch with tbench on top of of the schedstat patches that
>>> track SIS efficiency. The tracking adds overhead so it's not a perfect
>>> performance comparison but the expectation
On Mon, 14 Dec 2020 at 06:48, Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> In file included from include/linux/kernel.h:14,
> from include/linux/list.h:9,
> from
On Sun, Dec 13, 2020 at 5:22 PM Christophe JAILLET
wrote:
> A previous 'rcar_fcp_get()' call must be undone in the error handling path,
> as already done in the remove function.
>
> Fixes: 94fcdf829793 ("[media] v4l: vsp1: Add FCP support")
> Signed-off-by: Christophe JAILLET
Reviewed-by: Geert
In hci_uart_write_work, there is a loop/goto checking the value of
HCI_UART_TX_WAKEUP. If HCI_UART_TX_WAKEUP is set again, it keeps trying
hci_uart_dequeue; otherwise, it clears HCI_UART_SENDING and returns.
In hci_uart_tx_wakeup, if HCI_UART_SENDING is already set, it sets
HCI_UART_TX_WAKEUP,
在 2020/12/11 23:46, Rob Herring 写道:
On Fri, Nov 20, 2020 at 03:48:48PM +0800, Qinglang Miao wrote:
When put_device(>dev) being called, kfree(bridge) is inside
of release function, so the following device_del would cause a
use-after-free bug.
Fixes: 37d6a0a6f470 ("PCI: Add
Hi Will, Marc,
On 2020/12/11 18:00, Will Deacon wrote:
On Fri, Dec 11, 2020 at 09:49:28AM +, Marc Zyngier wrote:
On 2020-12-11 08:01, Yanan Wang wrote:
@@ -461,25 +462,56 @@ static int stage2_map_set_prot_attr(enum
kvm_pgtable_prot prot,
return 0;
}
+static bool
On 2020/12/11 17:49, Marc Zyngier wrote:
Hi Yanan,
On 2020-12-11 08:01, Yanan Wang wrote:
In dirty-logging, or dirty-logging-stopped time, even normal running
time of a guest configed with huge mappings and numbers of vCPUs,
translation faults by different vCPUs on the same GPA could occur
On 2020/12/11 17:53, Will Deacon wrote:
Hi Yanan,
On Fri, Dec 11, 2020 at 04:01:15PM +0800, Yanan Wang wrote:
In dirty-logging, or dirty-logging-stopped time, even normal running
time of a guest configed with huge mappings and numbers of vCPUs,
translation faults by different vCPUs on the
On 12/8/20 6:53 AM, Xiaoming Ni wrote:
> On 2020/12/8 2:59, Vignesh Raghavendra wrote:
>> Hi Xiaoming,
>>
[...]
> ---
> drivers/mtd/chips/cfi_cmdset_0002.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c
Hello Shimoda-san,
On Mon, 2020-12-14 at 04:57 +, Yoshihiro Shimoda wrote:
> Hello Matti-san,
>
> > From: Vaittinen, Matti, Sent: Friday, December 11, 2020 9:34 PM
> >
> > Hello again Shimada-san,
> >
> > On Fri, 2020-12-11 at 20:27 +0900, Yoshihiro Shimoda wrote:
> > > Add support for
Hi Mark,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 2c85ebc57b3e1817b6ce1a6b703928e113a90442
commit: ed3768db588291ddb5dc794daed12cc751373566 arm64: entry: convert el1_sync
to C
date: 1 year, 2 months ago
On Fri, Dec 11, 2020 at 10:08:54AM +0100, Markus Elfring wrote:
> > This makes it hard to review any patches or follow discussion...
>
> You shared also special software development opinions about extra variable
> initialisations occasionally, didn't you?
I generally put everything at the top of
On Fri, Dec 11, 2020 at 9:56 PM Johannes Thumshirn
wrote:
>
> On 11/12/2020 15:57, SelvaKumar S wrote:
> [...]
> > +int blk_copy_emulate(struct block_device *bdev, struct blk_copy_payload
> > *payload,
> > + gfp_t gfp_mask)
> > +{
> > + struct request_queue *q =
On 12/13/20 10:53 PM, Nicholas Piggin wrote:
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 84faaba66364..e69c974369cc 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -443,9 +443,22 @@ config MMU_LAZY_TLB
> config MMU_LAZY_TLB_REFCOUNT
> def_bool y
> depends on MMU_LAZY_TLB
On 14-12-20, 08:54, Peter Ujfalusi wrote:
> Use ERR_CAST() when devm_ioremap_resource() fails.
>
> Reported-by: kernel test robot
Applied, thanks
--
~Vinod
Use _lazy_tlb functions for lazy mm refcounting in powerpc, to prepare
to move to MMU_LAZY_TLB_SHOOTDOWN.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index
On a 16-socket 192-core POWER8 system, a context switching benchmark
with as many software threads as CPUs (so each switch will go in and
out of idle), upstream can achieve a rate of about 1 million context
switches per second. After this patch it goes up to 118 million.
Signed-off-by: Nicholas
Add CONFIG_MMU_LAZY_TLB which can be configured out to disable
the lazy tlb mechanism entirely, and switches to init_mm when
switching to a kernel thread.
NOMMU systems could easily go without this and save a bit of code
and the refcount atomics, because their mm switch is a no-op. They
have not
On big systems, the mm refcount can become highly contented when doing
a lot of context switching with threaded applications (particularly
switching between the idle thread and an application thread).
Abandoning lazy tlb slows switching down quite a bit in the important
user->idle->user cases, so
Add explicit _lazy_tlb annotated functions for lazy mm refcounting.
This makes things a bit more explicit, and allows explicit refcounting
to be removed if it is not used.
Signed-off-by: Nicholas Piggin
---
arch/arm/mach-rpc/ecard.c| 2 +-
arch/powerpc/mm/book3s64/radix_tlb.c | 4
On Fri, Dec 11, 2020 at 11:35 PM Keith Busch wrote:
>
> On Fri, Dec 11, 2020 at 07:21:38PM +0530, SelvaKumar S wrote:
> > +int blk_copy_emulate(struct block_device *bdev, struct blk_copy_payload
> > *payload,
> > + gfp_t gfp_mask)
> > +{
> > + struct request_queue *q =
Use ERR_CAST() when devm_ioremap_resource() fails.
Reported-by: kernel test robot
Signed-off-by: Peter Ujfalusi
---
Hi Vinod,
it came to my attention too late. This patch fixes the sparse warnig introduced
by the AM64 support in
This is another rebase, on top of mainline now (don't need the
asm-generic tree), and without any x86 or membarrier changes.
This makes the series far smaller and more manageable and
without the controversial bits.
Thanks,
Nick
Nicholas Piggin (5):
lazy tlb: introduce lazy mm refcount helper
On 12/11/20 6:40 AM, Florent Revest wrote:
On Wed, Dec 2, 2020 at 10:18 PM Alexei Starovoitov
wrote:
I still think that adopting printk/vsnprintf for this instead of
reinventing the wheel
is more flexible and easier to maintain long term.
Almost the same layout can be done with vsnprintf
Simplify the return expression.
Signed-off-by: Zheng Yongjun
---
drivers/leds/leds-ss4200.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/leds/leds-ss4200.c b/drivers/leds/leds-ss4200.c
index 245de443fe9c..97abab439826 100644
--- a/drivers/leds/leds-ss4200.c
Hi Matti-san,
Thank you for your review!
> From: Vaittinen, Matti, Sent: Friday, December 11, 2020 10:29 PM
>
> Hi Yoshihiro-san,
>
> On Fri, 2020-12-11 at 20:27 +0900, Yoshihiro Shimoda wrote:
> > From: Khiem Nguyen
> >
> > Since the driver supports BD9571MWV PMIC only,
> > this patch makes
On Sun, Dec 13, 2020 at 02:15:45PM +, Jonathan Cameron wrote:
> On Mon, 7 Dec 2020 17:18:18 +0800
> "Ye, Xiang" wrote:
>
> > Hi Jonathan
> >
> > Thanks for review and comments.
> >
> > On Sat, Dec 05, 2020 at 04:05:40PM +, Jonathan Cameron wrote:
> > > On Thu, 3 Dec 2020 11:53:52
On Sun, Dec 13, 2020 at 11:46 AM Ian Kent wrote:
>
> On Fri, 2020-12-11 at 10:17 +0800, Ian Kent wrote:
> > On Fri, 2020-12-11 at 10:01 +0800, Ian Kent wrote:
> > > > For the patches, there is a mutex_lock in kn->attr_mutex, as
> > > > Tejun
> > > > mentioned here
> > > >
On 12/13/20 9:23 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the watchdog tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from include/linux/device.h:15,
> from include/linux/acpi.h:15,
> from
When codec probe fails, it doesn't enable runtime suspend, and can
prevent graphics card from getting powered down:
[4.280991] snd_hda_intel :01:00.1: no codecs initialized
$ cat /sys/bus/pci/devices/:01:00.1/power/runtime_status
active
So enable runtime PM when codec probe fails, to
On Fri, 2020-12-11 at 22:11 +0530, Puranjay Mohan wrote:
> PCI core calls __pcie_print_link_status() for every device, it prints
> both the link width and the link speed. skd_pci_info() does the same
> thing again, hence it can be removed.
Hmmm... On my box, I see this for the skd card:
[
On 12/11/20 4:52 PM, Zheng Yongjun wrote:
> Replace a comma between expression statements by a semicolon.
>
> Signed-off-by: Zheng Yongjun
Thanks for the catch. Added in my 2nd wave series.
Coly Li
> ---
> drivers/md/bcache/sysfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
The SPI controller has the following characteristics:
- Full-duplex synchronous serial data transmission
- Support up to 4 variable length byte transmission
- Main mode support
- Mode failure generates an error flag and issues an interrupt request
- Double buffer receiver
- Serial clock with
add spi support.
Signed-off-by: Qing Zhang
---
v2:
- Add spi about pci device DT
v3:
- Remove spiflash node
---
arch/mips/boot/dts/loongson/ls7a-pch.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
This is now supported, enable for Loongson systems.
Signed-off-by: Qing Zhang
---
v2:
- Modify CONFIG_SPI_LOONGSON to CONFIG_SPI_LS7A
v3:
- No changes
---
arch/mips/configs/loongson3_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/mips/configs/loongson3_defconfig
Switch the DT binding to a YAML schema to enable the DT validation.
Signed-off-by: Qing Zhang
---
.../devicetree/bindings/spi/loongson,spi-ls7a.yaml | 49 ++
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
Hi Linus:
API:
- Add speed testing on 1420-byte blocks for networking.
Algorithms:
- Improve performance of chacha on ARM for network packets.
- Improve performance of aegis128 on ARM for network packets.
Drivers:
- Add support for Keem Bay OCS AES/SM4.
- Add support for QAT 4xxx devices.
-
The following changes since commit 09162bc32c880a791c6c0668ce0745cf7958f576:
Linux 5.10-rc4 (2020-11-15 16:44:31 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/fs/fscrypt/fscrypt.git tags/fsverity-for-linus
for you to fetch changes up to
Excerpts from Nicholas Piggin's message of December 14, 2020 2:07 pm:
> Excerpts from Andy Lutomirski's message of December 11, 2020 10:11 am:
>>> On Dec 5, 2020, at 7:59 PM, Nicholas Piggin wrote:
>>>
>>
>>> I'm still going to persue shoot-lazies for the merge window. As you
>>> see it's about
On Mon, Dec 14, 2020 at 12:31:47AM -0500, Dave Jones wrote:
> On Sun, Dec 13, 2020 at 03:03:29PM -0800, Linus Torvalds wrote:
> > Ok, here it is - 5.10 is tagged and pushed out.
> >
> > I pretty much always wish that the last week was even calmer than it
> > was, and that's true here too.
The following changes since commit 09162bc32c880a791c6c0668ce0745cf7958f576:
Linux 5.10-rc4 (2020-11-15 16:44:31 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/fs/fscrypt/fscrypt.git tags/fscrypt-for-linus
for you to fetch changes up to
On Fri, Dec 11, 2020 at 4:44 PM Miklos Szeredi wrote:
>
> On Tue, Dec 8, 2020 at 12:32 PM Amir Goldstein wrote:
> >
> > On Mon, Dec 7, 2020 at 6:37 PM Miklos Szeredi wrote:
> > >
> > > In case the file cannot be opened with O_NOATIME because of lack of
> > > capabilities, then clear O_NOATIME
Hi all,
After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
In file included from include/linux/kernel.h:14,
from include/linux/list.h:9,
from include/linux/wait.h:7,
from
Hi guys,
any ideas?
--
Thanks,
Ruan Shiyang.
On 2020/11/26 下午12:03, Shiyang Ruan wrote:
The 'err' was assigned to -ENOMEM in just few lines above, no need to be
assigned again.
Signed-off-by: Shiyang Ruan
---
fs/fuse/dir.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/fuse/dir.c
[+cc Jesse, Tony, David, Jakub, Heiner, lists in case there's an ASPM
issue with I211 or Realtek NICs. Beginning of thread:
https://lore.kernel.org/r/20201024205548.1837770-1-ian.kuml...@gmail.com
Short story: Ian has:
Root Port --- Switch --- I211 NIC
\-- multifunction
On Thu, Dec 10, 2020 at 5:18 PM Miklos Szeredi wrote:
>
> On Tue, Dec 8, 2020 at 12:15 PM Amir Goldstein wrote:
> >
> > On Mon, Dec 7, 2020 at 6:36 PM Miklos Szeredi wrote:
> > >
> > > ovl_ioctl_set_flags() does a capability check using flags, but then the
> > > real ioctl double-fetches flags
On Sun, Dec 13, 2020 at 03:03:29PM -0800, Linus Torvalds wrote:
> Ok, here it is - 5.10 is tagged and pushed out.
>
> I pretty much always wish that the last week was even calmer than it
> was, and that's true here too. There's a fair amount of fixes in here,
> including a few last-minute
Instead of open coding DEVICE_ATTR() defines, use the
DEVICE_ATTR_RW(), DEVICE_ATTR_WO(), and DEVICE_ATTR_RO()
macros.
This required a few functions to be renamed, but the functionality
itself is unchanged.
Reviewed-by: Lukas Bulwahn
Signed-off-by: Dwaipayan Ray
---
Changes in v2:
- Reword
On Mon, Dec 14, 2020 at 12:31:47AM -0500, Dave Jones wrote:
> On Sun, Dec 13, 2020 at 03:03:29PM -0800, Linus Torvalds wrote:
> > Ok, here it is - 5.10 is tagged and pushed out.
> >
> > I pretty much always wish that the last week was even calmer than it
> > was, and that's true here
Hi all,
After merging the watchdog tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/linux/device.h:15,
from include/linux/acpi.h:15,
from drivers/watchdog/iTCO_wdt.c:48:
drivers/watchdog/iTCO_wdt.c: In function
xhci-mtk has hooks on add_endpoint() and drop_endpoint() from xhci
to handle its own sw bandwidth managements and stores bandwidth data
into internal table every time add_endpoint() is called,
so when bandwidth allocation fails at one endpoint, all earlier
allocation from the same interface could
Hi Matti-san,
Thank you for your review!
> From: Vaittinen, Matti, Sent: Friday, December 11, 2020 9:55 PM
>
> On Fri, 2020-12-11 at 20:27 +0900, Yoshihiro Shimoda wrote:
> > Add support for BD9574MWF which is silimar chip with BD9571MWV.
> > Note that BD9574MWF has an additional feature, but
Hi,
Seems like kernel timer implementation is buggy since some kernel
version (between 3.16.0 and 4.9.0).
Comments for add_timer in timer.c:
* The kernel will do a ->function(@timer) callback from the
* timer interrupt at the ->expires point in the future. The
* current time is 'jiffies'.
From: Chunyan Zhang
If the i2c device SCL bus being pulled up due to some exception before
message transfer done, the system cannot receive the completing interrupt
signal any more, it would not exit waiting loop until MAX_SCHEDULE_TIMEOUT
jiffies eclipse, that would make the system seemed hang
Hello Matti-san,
> From: Vaittinen, Matti, Sent: Friday, December 11, 2020 9:34 PM
>
> Hello again Shimada-san,
>
> On Fri, 2020-12-11 at 20:27 +0900, Yoshihiro Shimoda wrote:
> > Add support for BD9574MWF which is silimar chip with BD9571MWV.
> > Note that BD9574MWF doesn't support AVS and
在 2020-12-14星期一的 01:35 +，André Przywara写道：
> On 13/12/2020 18:24, Icenowy Zheng wrote:
> > 在 2020-12-11星期五的 01:19 +，Andre Przywara写道：
> > > Newer SoCs (A100, H616) need to clear a different bit in our
> > > "unknown"
> > > PMU PHY register.
> >
> > It looks like that the unknown PHY
Hi Taniya,
On 13-12-20, 14:00, Taniya Das wrote:
>
>
> On 12/11/2020 12:40 PM, Stephen Boyd wrote:
> > Quoting Vinod Koul (2020-12-10 21:43:49)
> > > On 10-12-20, 12:43, Stephen Boyd wrote:
> > > > > +static struct clk_branch gcc_camera_ahb_clk = {
> > > > > + .halt_reg = 0x26004,
> > > >
syzbot has found a reproducer for the following issue on:
HEAD commit:6bff9bb8 Merge tag 'scsi-fixes' of git://git.kernel.org/pu..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10937c5b50
kernel config:
Hi Nadeem,
On 12/12/20 12:37 pm, Athani Nadeem Ladkhan wrote:
> Hi Rob / Kishon,
>
>> -Original Message-
>> From: Rob Herring
>> Sent: Friday, December 11, 2020 10:32 PM
>> To: Athani Nadeem Ladkhan
>> Cc: Tom Joseph ; Lorenzo Pieralisi
>> ; Bjorn Helgaas ; PCI
>> ;
Hi all,
After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/md/raid0.c: In function 'raid0_handle_discard':
drivers/md/raid0.c:511:26: error: passing argument 1 of 'trace_block_bio_remap'
from incompatible pointer type
Excerpts from Geert Uytterhoeven's message of December 10, 2020 7:06 pm:
> Hi Nicholas,
>
> On Fri, Nov 20, 2020 at 4:01 AM Nicholas Piggin wrote:
>>
>> When offlining a CPU, powerpc/64s does not flush TLBs, rather it just
>> leaves the CPU set in mm_cpumasks, so it continues to receive TLBIEs
Excerpts from Andy Lutomirski's message of December 11, 2020 10:11 am:
>> On Dec 5, 2020, at 7:59 PM, Nicholas Piggin wrote:
>>
>
>> I'm still going to persue shoot-lazies for the merge window. As you
>> see it's about a dozen lines and a if (IS_ENABLED(... in core code.
>> Your change is common
On 12/11/2020 6:55 PM, Alexander Potapenko wrote:
> On Fri, Dec 11, 2020 at 1:45 PM Vijayanand Jitta
> wrote:
>>
>>
>>
>> On 12/11/2020 2:06 PM, Alexander Potapenko wrote:
>>> On Thu, Dec 10, 2020 at 6:01 AM wrote:
From: Yogesh Lal
Add a kernel parameter stack_hash_order
Hi all,
Today's linux-next merge of the block tree got a conflict in:
drivers/md/raid10.c
between commit:
17c28c2a0687 ("Revert "md/raid10: extend r10bio devs to raid disks"")
from the origin tree and commit:
93decc563637 ("md/raid10: initialize r10_bio->read_slot before use.")
from
The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2.
On platforms with Zhaoxin CPUs supporting this X86 feature, when
crc32c-intel and crc32c-generic are both registered, system will
use crc32c-intel because its .cra_priority is greater than
crc32c-generic.
When doing lmbench3 Create
Hi all,
Today's linux-next merge of the block tree got a conflict in:
drivers/md/md.c
between commit:
57a0f3a81ef2 ("Revert "md: add md_submit_discard_bio() for submitting discard
bio"")
from Linus' tree and commit:
1c02fca620f7 ("block: remove the request_queue argument to the
This patchset supports some dfl device drivers written in userspace.
In the patchset v1, the "driver_override" interface should be used to bind
the DFL UIO driver to DFL devices. But there is concern that the
"driver_override" interface is not OK itself. So in v2, we use a new
matching
This patch adds description for UIO support for dfl devices on DFL
bus.
Signed-off-by: Xu Yilun
---
v2: no doc in v1, add it for v2.
---
Documentation/fpga/dfl.rst | 23 +++
1 file changed, 23 insertions(+)
diff --git a/Documentation/fpga/dfl.rst
During system resume/suspend, hba could be NULL. In this case, do not touch
eh_sem.
Fixes: 88a92d6ae4fe ("scsi: ufs: Serialize eh_work with system PM events and
async scan")
Signed-off-by: Can Guo
---
drivers/scsi/ufs/ufshcd.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
This patch supports the DFL drivers be written in userspace. This is
realized by exposing the userspace I/O device interfaces.
The driver leverages the uio_pdrv_genirq, it adds the uio_pdrv_genirq
platform device with the DFL device's resources, and let the generic UIO
platform device driver
On Fri, 2020-12-11 at 14:36 +0800, Ikjoon Jang wrote:
> On Fri, Dec 11, 2020 at 9:53 AM Chunfeng Yun
> wrote:
> >
> > On Thu, 2020-12-10 at 18:47 +0800, Ikjoon Jang wrote:
> > > xhci-mtk releases allocated TT bandwidth data only when whole
> > > endpoints of a device are dropped as there're only
subject prefix should be
leds: ss4200: simplify the return expression of register_nasgpio_led
Update rk3399-puma.dtsi with the vendor prefix referred in
vendor-prefixes.yaml.
Optional property: rockchip,drive-impedance-ohm
Signed-off-by: Chris Ruehl
---
arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Update the implementation add "rockchip," vendor prefix for the
optional dts properties. Prefix referred from vendor-prefixes.yaml
Signed-off-by: Chris Ruehl
---
drivers/phy/rockchip/phy-rockchip-emmc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
Update rk3399.dtsi with the vendor prefix referred in vendor-prefixes.yaml.
Optional property: rockchip,drive-impedance-ohm
Signed-off-by: Chris Ruehl
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
This patchset follow up with commit 8b5c2b45b8f0a and a8cef928276bb
Following the reference in vendor-prefixes.yaml, update implementation,
devicetree binding dtsi and documentation for the phy-rockchip-emmc.
Signed-off-by: Chris Ruehl
---
Update the documentation and add the vendor prefix to the optional
properties referred in vendor-prefixes.yaml.
Signed-off-by: Chris Ruehl
---
.../bindings/phy/rockchip-emmc-phy.txt| 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git
On 14/12/2020 10:47 am, Chris Ruehl wrote:
This patchset follow up with commit
Following the reference in vendor-prefixes.yaml, update implementation,
devicetree binding dtsi and documentation for the phy-rockchip-emmc.
Signed-off-by: Chris Ruehl
---
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
MAINTAINERS
between commit:
885743324513 ("crypto: keembay - Add support for Keem Bay OCS AES/SM4")
from the crypto tree and commit:
ed794057b052 ("drm/kmb: Build files for KeemBay Display driver")
from the drm tree.
lyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20201213
i386 randconfig-a004-20201213
i386 randconfig-a003-20201213
i386 randconfig-a002-202
In several patches work has been done to enable NFSv4 to use user
namespaces:
58002399da65: NFSv4: Convert the NFS client idmapper to use the container user
namespace
3b7eb5e35d0f: NFS: When mounting, don't share filesystems between different
user namespaces
Unfortunately, the userspace APIs
This is a resend[2] for consideration into the next NFS client merge window.
Right now, it is possible to mount NFS with an non-matching super block
user ns, and NFS sunrpc user ns. This (for the user) results in an awkward
set of interactions if using anything other than auth_null, where the
There was refactoring done to use the fs_context for mounting done in:
62a55d088cd87: NFS: Additional refactoring for fs_context conversion
This made it so that the net_ns is fetched from the fs_context (the netns
that fsopen is called in). This change also makes it so that the credential
fetched
Update rk3399-puma.dtsi with the vendor prefix referred in
vendor-prefixes.yaml.
Optional property: rockchip,drive-impedance-ohm
Signed-off-by: Chris Ruehl
---
arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Update rk3399.dtsi with the vendor prefix referred in vendor-prefixes.yaml.
Optional property: rockchip,drive-impedance-ohm
Signed-off-by: Chris Ruehl
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
This patchset follow up with commit
Following the reference in vendor-prefixes.yaml, update implementation,
devicetree binding dtsi and documentation for the phy-rockchip-emmc.
Signed-off-by: Chris Ruehl
---
Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt | 19
++-
Update the implementation add "rockchip," vendor prefix for the
optional dts properties. Prefix referred from vendor-prefixes.yaml
Signed-off-by: Chris Ruehl
---
drivers/phy/rockchip/phy-rockchip-emmc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
Hi Andrew & Rob,
Do you have any suggestion on this patch?
Or should I send a v3 patch with the commits reordering for the review?
Thanks.
Chiawei
> -Original Message-
> From: Andrew Jeffery
> Sent: Monday, October 26, 2020 11:12 AM
> To: ChiaWei Wang ; Rob Herring
> ; Joel Stanley
>
On 12/12/2020 18:54, Ard Biesheuvel wrote:
> On Sat, 12 Dec 2020 at 10:36, Ard Biesheuvel wrote:
>>
>> On Fri, 11 Dec 2020 at 20:07, Eric Biggers wrote:
>>>
>>> On Fri, Dec 11, 2020 at 07:29:04PM +0800, Tony W Wang-oc wrote:
The driver crc32c-intel match CPUs supporting
On 12/12/2020 01:43, Eric Biggers wrote:
> On Fri, Dec 11, 2020 at 07:29:04PM +0800, Tony W Wang-oc wrote:
>> The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2.
>> On platforms with Zhaoxin CPUs supporting this X86 feature, When
>> crc32c-intel and crc32c-generic are both
trace_note_tsk() is called by __blk_add_trace(), which is covered by RCU read
lock.
So in case of PREEMPT_RT, warning of 'BUG: sleeping function called from
invalid context'
will be triggered because spin lock is converted to rtmutex.
Fix the issue by converting running_trace_lock into
Hi all,
After merging the net-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
fs/cifs/cifs_swn.c: In function 'cifs_swn_notify':
fs/cifs/cifs_swn.c:450:4: error: implicit declaration of function
'nla_strlcpy'; did you mean 'nla_strscpy'?
During system resume/suspend, hba could be NULL. In this case, do not touch
eh_sem.
Fixes: 88a92d6ae4fe ("scsi: ufs: Serialize eh_work with system PM events and
async scan")
Signed-off-by: Can Guo
---
drivers/scsi/ufs/ufshcd.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
On Tue, Jul 07, 2020 at 01:31:37PM +0800, Chinwen Chang wrote:
[..]
> > > Hi Laurent,
> > >
> > > We merged SPF v11 and some patches from v12 into our platforms. After
> > > several experiments, we observed SPF has obvious improvements on the
> > > launch time of applications, especially for
allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a003-20201213
x86_64 randconfig-a006-20201213
x86_64 randconfig-a002-20201213
x86_64 randconfig-a005-20201213
x86_64
On 13/12/2020 18:24, Icenowy Zheng wrote:
> 在 2020-12-11星期五的 01:19 +，Andre Przywara写道：
>> Newer SoCs (A100, H616) need to clear a different bit in our
>> "unknown"
>> PMU PHY register.
>
> It looks like that the unknown PHY register is PHYCTL register for each
> individual PHY, and the bit
The SCU offset for signal PWM8 in group PWM8G0 is wrong, fix it from
SCU414 to SCU4B4.
Besides that, When PWM8~15 of PWMG0 set it needs to clear SCU414 bits
at the same time.
Fixes: 2eda1cdec49f ("pinctrl: aspeed: Add AST2600 pinmux support")
Signed-off-by: Billy Tsai
---
On 13/12/2020 17:47, Icenowy Zheng wrote:
Hi Icenowy,
> 在 2020-12-11星期五的 01:19 +，Andre Przywara写道：
>> Hi,
>>
>> this is the quite expanded second version of the support series for
>> the
>> Allwinner H616 SoC.
>> Besides many fixes for the bugs discovered by the diligent reviewers
>> (many
On Wed, Nov 18, 2020 at 4:39 PM Atish Patra wrote:
>
> This series attempts to move the ARM64 numa implementation to common
> code so that RISC-V can leverage that as well instead of reimplementing
> it again.
>
> RISC-V specific bits are based on initial work done by Greentime Hu [1] but
>
On 12/7/20 11:11 PM, Wilken Gottwalt wrote:
> On Mon, 7 Dec 2020 21:22:23 -0600
> Samuel Holland wrote:
>
>> On 12/7/20 10:12 AM, Maxime Ripard wrote:
>>> Hi,
>>>
>>> On Mon, Dec 07, 2020 at 05:05:03PM +0100, Wilken Gottwalt wrote:
Adds documentation on how to use the sun8i_hwspinlock
1 - 100 of 404 matches
Mail list logo
