Re: [RFC PATCH v7] sched/fair: select idle cpu from idle cpumask for task wakeup
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 would be that the patch reduces >>> the number of runqueues that are scanned >> >> Thanks for the measurement! I don't play with tbench so may need a while >> to digest the data. >> > > They key point is that it appears the idle mask was mostly equivalent to > the full domain mask, at least for this test. > >>> >>> tbench4 >>> 5.10.0-rc6 5.10.0-rc6 >>> schedstat-v1r1 idlemask-v7r1 >>> Hmean 1504.76 ( 0.00%) 500.14 * -0.91%* >>> Hmean 2 1001.22 ( 0.00%) 970.37 * -3.08%* >>> Hmean 4 1930.56 ( 0.00%) 1880.96 * -2.57%* >>> Hmean 8 3688.05 ( 0.00%) 3537.72 * -4.08%* >>> Hmean 16 6352.71 ( 0.00%) 6439.53 * 1.37%* >>> Hmean 32 10066.37 ( 0.00%)10124.65 * 0.58%* >>> Hmean 64 12846.32 ( 0.00%)11627.27 * -9.49%* I focused on this case and run it 5 times, and here is the data on my side. 5 times x 600s tbench, thread number is 153(80% x 192(h/w thread num)). Hmean 153 v5.9.12 v5.9.12 schedstat-v1idlemask-v8(with schedstat) Round 1 15717.3 15608.1 Round 2 14856.9 15642.5 Round 3 14856.7 15782.1 Round 4 15408.9 15912.9 Round 5 15436.6 15927.7 >From tbench throughput data, bigger is better, it looks like idlemask wins And here is SIS_scanned data: Hmean 153 v5.9.12 v5.9.12 schedstat-v1idlemask-v8(with schedstat) Round 1 22562490432 21894932302 Round 2 21288529957 21693722629 Round 3 20657521771 21268308377 Round 4 21868486414 22289128955 Round 5 21859614988 22214740417 >From SIS_scanned data, less is better, it looks like the default one is better. But combined with throughput data, this can be explained as bigger throughput performs more SIS_scanned. So at least, there is no regression of this case. Thanks, -Aubrey
Re: linux-next: build warning after merge of the tip tree
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 include/linux/wait.h:7, > from include/linux/wait_bit.h:8, > from include/linux/fs.h:6, > from include/linux/proc_fs.h:10, > from include/linux/efi.h:19, > from drivers/firmware/efi/libstub/arm32-stub.c:5: > drivers/firmware/efi/libstub/arm32-stub.c: In function 'handle_kernel_image': > include/linux/minmax.h:18:28: warning: comparison of distinct pointer types > lacks a cast >18 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) > |^~ > include/linux/minmax.h:32:4: note: in expansion of macro '__typecheck' >32 | (__typecheck(x, y) && __no_side_effects(x, y)) > |^~~ > include/linux/minmax.h:42:24: note: in expansion of macro '__safe_cmp' >42 | __builtin_choose_expr(__safe_cmp(x, y), \ > |^~ > include/linux/minmax.h:58:19: note: in expansion of macro '__careful_cmp' >58 | #define max(x, y) __careful_cmp(x, y, >) > | ^ > arch/arm/include/asm/efi.h:74:25: note: in expansion of macro 'max' >74 | #define EFI_PHYS_ALIGN max(SZ_2M, roundup_pow_of_two(TEXT_OFFSET)) > | ^~~ > drivers/firmware/efi/libstub/arm32-stub.c:123:44: note: in expansion of macro > 'EFI_PHYS_ALIGN' > 123 | int alloc_size = MAX_UNCOMP_KERNEL_SIZE + EFI_PHYS_ALIGN; > |^~ ... Thanks for the report. I actually spotted this and sent a fix yesterday [0]. I'll send it to -tip today. [0] https://lore.kernel.org/linux-efi/20201213151306.73558-1-a...@kernel.org/
Re: [PATCH] media: vsp1: Fix an error handling path in the probe function
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 Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] Bluetooth: hci_uart: Fix a race for write_work scheduling
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, skips schedule_work and assumes the running/pending
hci_uart_write_work worker will do hci_uart_dequeue properly.
However, if the HCI_UART_SENDING check in hci_uart_tx_wakeup is done after
the loop breaks, but before HCI_UART_SENDING is cleared in
hci_uart_write_work, the schedule_work is skipped incorrectly.
Fix this race by changing the order of HCI_UART_SENDING and
HCI_UART_TX_WAKEUP modification.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Fixes: 82f5169bf3d3 ("Bluetooth: hci_uart: add serdev driver support library")
Signed-off-by: Claire Chang
---
drivers/bluetooth/hci_ldisc.c | 7 +++
drivers/bluetooth/hci_serdev.c | 4 ++--
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index f83d67eafc9f..8be4d807d137 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -127,10 +127,9 @@ int hci_uart_tx_wakeup(struct hci_uart *hu)
if (!test_bit(HCI_UART_PROTO_READY, >flags))
goto no_schedule;
- if (test_and_set_bit(HCI_UART_SENDING, >tx_state)) {
- set_bit(HCI_UART_TX_WAKEUP, >tx_state);
+ set_bit(HCI_UART_TX_WAKEUP, >tx_state);
+ if (test_and_set_bit(HCI_UART_SENDING, >tx_state))
goto no_schedule;
- }
BT_DBG("");
@@ -174,10 +173,10 @@ static void hci_uart_write_work(struct work_struct *work)
kfree_skb(skb);
}
+ clear_bit(HCI_UART_SENDING, >tx_state);
if (test_bit(HCI_UART_TX_WAKEUP, >tx_state))
goto restart;
- clear_bit(HCI_UART_SENDING, >tx_state);
wake_up_bit(>tx_state, HCI_UART_SENDING);
}
diff --git a/drivers/bluetooth/hci_serdev.c b/drivers/bluetooth/hci_serdev.c
index ef96ad06fa54..9e03402ef1b3 100644
--- a/drivers/bluetooth/hci_serdev.c
+++ b/drivers/bluetooth/hci_serdev.c
@@ -83,9 +83,9 @@ static void hci_uart_write_work(struct work_struct *work)
hci_uart_tx_complete(hu, hci_skb_pkt_type(skb));
kfree_skb(skb);
}
- } while (test_bit(HCI_UART_TX_WAKEUP, >tx_state));
- clear_bit(HCI_UART_SENDING, >tx_state);
+ clear_bit(HCI_UART_SENDING, >tx_state);
+ } while (test_bit(HCI_UART_TX_WAKEUP, >tx_state));
}
/* --- Interface to HCI layer -- */
--
2.29.2.576.ga3fc446d84-goog
Re: [PATCH] PCI: fix use-after-free in pci_register_host_bridge
在 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 pci_register_host_bridge() interface")
That commit did have some problems, but this patch doesn't apply to that
commit. See commits 1b54ae8327a4 and 9885440b16b8.
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/pci/probe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 4289030b0..82292e87e 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -991,8 +991,8 @@ static int pci_register_host_bridge(struct pci_host_bridge
*bridge)
return 0;
unregister:
- put_device(>dev);
device_del(>dev);
+ put_device(>dev);
I don't think this is right.
Let's look at pci_register_host_bridge() with only the relevant
sections:
static int pci_register_host_bridge(struct pci_host_bridge *bridge)
{
...
err = device_add(>dev);
if (err) {
put_device(>dev);
goto free;
}
bus->bridge = get_device(>dev);
...
if (err)
goto unregister;
...
return 0;
unregister:
put_device(>dev);
device_del(>dev);
free:
kfree(bus);
return err;
}
The documentation for device_add says this:
* Rule of thumb is: if device_add() succeeds, you should call
* device_del() when you want to get rid of it. If device_add() has
* *not* succeeded, use *only* put_device() to drop the reference
* count.
The put_device at the end is to balance the get_device after device_add.
It will *only* decrement the use count. Then we call device_del as the
documentation says.
Rob
.
Hi, Rob
Your words make sence to me: the code is *logicly* correct here and
won't raise a use-after-free bug. I do hold a misunderstanding of this
one, sorry for that ~
But I still think this patch should be reconsidered:
The kdoc of device_unregister explicitly mentions the possibility that
other refs might continue to exist after device_unregister was called,
and *del_device* is first part of it.
By the way, 'del_device() called before put_device()' is everywhere in
kernel code, like device_unregister(), pci_destroy_dev() or
switchtec_pci_remove()
In fact, I can't find another place in kernel code looks like:
put_device(x);
device_del(x);
So I guess put_device() ought to be the last time we touch the object
(I don't find evidence strong enough in kdoc to prove this) and putting
put_device after device_del is a more natural logic.
Qinglang
.
Re: [RFC PATCH] KVM: arm64: Add prejudgement for relaxing permissions only case in stage2 translation fault handler
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 stage2_set_valid_leaf_pte_pre(u64 addr, u32 level,
+ kvm_pte_t *ptep, kvm_pte_t new,
+ struct stage2_map_data *data)
+{
+ kvm_pte_t old = *ptep, old_attr, new_attr;
+
+ if ((old ^ new) & (~KVM_PTE_LEAF_ATTR_PERMS))
+ return false;
+
+ /*
+* Skip updating if we are trying to recreate exactly the same mapping
+* or to reduce the access permissions only. And update the valid leaf
+* PTE without break-before-make if we are trying to add more access
+* permissions only.
+*/
+ old_attr = (old & KVM_PTE_LEAF_ATTR_PERMS) ^
KVM_PTE_LEAF_ATTR_HI_S2_XN;
+ new_attr = (new & KVM_PTE_LEAF_ATTR_PERMS) ^
KVM_PTE_LEAF_ATTR_HI_S2_XN;
+ if (new_attr <= old_attr)
+ return true;
+
+ WRITE_ONCE(*ptep, new);
+ kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, data->mmu, addr, level);
I think what bothers me the most here is that we are turning a mapping into
a permission update, which makes the code really hard to read, and mixes
two things that were so far separate.
I wonder whether we should instead abort the update and simply take the
fault
again, if we ever need to do it.
That's a nice idea. If we could enforce that we don't alter permissions on
the map path, and instead just return e.g. -EAGAIN then that would be a
very neat solution and would cement the permission vs translation fault
division.
I agree with that we can indeed simplify the code, separate
permission-relaxing and
mapping by the *straightly return* way, although the cost is one more
vCPU trap on
permission fault next time possibly.
So how about the new two diffs below? I split them into two patches with
different aims.
Thanks,
Yanan.
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index 23a01dfcb27a..a74a62283012 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -170,10 +170,9 @@ static void kvm_set_table_pte(kvm_pte_t *ptep,
kvm_pte_t *childp)
smp_store_release(ptep, pte);
}
-static bool kvm_set_valid_leaf_pte(kvm_pte_t *ptep, u64 pa, kvm_pte_t attr,
- u32 level)
+static kvm_pte_t kvm_init_valid_leaf_pte(u64 pa, kvm_pte_t attr, u32 level)
{
- kvm_pte_t old = *ptep, pte = kvm_phys_to_pte(pa);
+ kvm_pte_t pte = kvm_phys_to_pte(pa);
u64 type = (level == KVM_PGTABLE_MAX_LEVELS - 1) ?
KVM_PTE_TYPE_PAGE :
KVM_PTE_TYPE_BLOCK;
@@ -181,12 +180,7 @@ static bool kvm_set_valid_leaf_pte(kvm_pte_t *ptep,
u64 pa, kvm_pte_t attr,
pte |= FIELD_PREP(KVM_PTE_TYPE, type);
pte |= KVM_PTE_VALID;
- /* Tolerate KVM recreating the exact same mapping. */
- if (kvm_pte_valid(old))
- return old == pte;
-
- smp_store_release(ptep, pte);
- return true;
+ return pte;
}
static int kvm_pgtable_visitor_cb(struct kvm_pgtable_walk_data *data,
u64 addr,
@@ -341,12 +335,17 @@ static int hyp_map_set_prot_attr(enum
kvm_pgtable_prot prot,
static bool hyp_map_walker_try_leaf(u64 addr, u64 end, u32 level,
kvm_pte_t *ptep, struct
hyp_map_data *data)
{
+ kvm_pte_t new, old = *ptep;
u64 granule = kvm_granule_size(level), phys = data->phys;
if (!kvm_block_mapping_supported(addr, end, phys, level))
return false;
- WARN_ON(!kvm_set_valid_leaf_pte(ptep, phys, data->attr, level));
+ /* Tolerate KVM recreating the exact same mapping. */
+ new = kvm_init_valid_leaf_pte(phys, data->attr, level);
+ if (old != new && !WARN_ON(kvm_pte_valid(old)))
+ smp_store_release(ptep, new);
+
data->phys += granule;
return true;
}
@@ -465,21 +464,29 @@ static bool stage2_map_walker_try_leaf(u64 addr,
u64 end, u32 level,
kvm_pte_t *ptep,
struct stage2_map_data *data)
{
+ kvm_pte_t new, old = *ptep;
u64 granule = kvm_granule_size(level), phys = data->phys;
+ struct page *page = virt_to_page(ptep);
if (!kvm_block_mapping_supported(addr, end, phys, level))
return false;
- if (kvm_pte_valid(*ptep))
- put_page(virt_to_page(ptep));
+ new = kvm_init_valid_leaf_pte(phys, data->attr, level);
+ if (kvm_pte_valid(old)) {
+ /* Tolerate KVM recreating the exact same mapping. */
+ if (old == new)
+ goto out;
- if (kvm_set_valid_leaf_pte(ptep, phys, data->attr, level))
- goto out;
+ /* There's an existing
Re: [RFC PATCH] KVM: arm64: Add prejudgement for relaxing permissions only case in stage2 translation fault handler
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
successively almost at the same time. There are two reasons for it.
(1) If there are some vCPUs accessing the same GPA at the same time
and the leaf PTE is not set yet, then they will all cause translation
faults and the first vCPU holding mmu_lock will set valid leaf PTE,
and the others will later choose to update the leaf PTE or not.
(2) When changing a leaf entry or a table entry with break-before-make,
if there are some vCPUs accessing the same GPA just catch the moment
when the target PTE is set invalid in a BBM procedure coincidentally,
they will all cause translation faults and will later choose to update
the leaf PTE or not.
The worst case can be like this: some vCPUs cause translation faults
on the same GPA with different prots, they will fight each other by
changing back access permissions of the PTE with break-before-make.
And the BBM-invalid moment might trigger more unnecessary translation
faults. As a result, some useless small loops will occur, which could
lead to vCPU stuck.
To avoid unnecessary update and small loops, add prejudgement in the
translation fault handler: Skip updating the valid leaf PTE if we are
trying to recreate exactly the same mapping or to reduce access
permissions only(such as RW-->RO). And update the valid leaf PTE without
break-before-make if we are trying to add more permissions only.
I'm a bit perplexed with this: why are you skipping the update if the
permissions need to be reduced? Even more, how can we reduce the
permissions from a vCPU fault? I can't really think of a scenario where
that happens.
Or are you describing a case where two vcpus fault simultaneously with
conflicting permissions:
- Both vcpus fault on translation fault
- vcpu A wants W access
- vpcu B wants R access
and 'A' gets in first, set the permissions to RW (because R is
implicitly added to W), followed by 'B' which downgrades it to RO?
If that's what you are describing, then I agree we could do better.
Yes, this is exactly what I want to describe.
Signed-off-by: Yanan Wang
---
arch/arm64/kvm/hyp/pgtable.c | 73 +---
1 file changed, 52 insertions(+), 21 deletions(-)
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index 23a01dfcb27a..f8b3248cef1c 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -45,6 +45,8 @@
#define KVM_PTE_LEAF_ATTR_HI_S2_XN BIT(54)
+#define KVM_PTE_LEAF_ATTR_PERMS (GENMASK(7, 6) | BIT(54))
+
struct kvm_pgtable_walk_data {
struct kvm_pgtable *pgt;
struct kvm_pgtable_walker *walker;
@@ -170,10 +172,9 @@ static void kvm_set_table_pte(kvm_pte_t *ptep,
kvm_pte_t *childp)
smp_store_release(ptep, pte);
}
-static bool kvm_set_valid_leaf_pte(kvm_pte_t *ptep, u64 pa,
kvm_pte_t attr,
- u32 level)
+static kvm_pte_t kvm_init_valid_leaf_pte(u64 pa, kvm_pte_t attr, u32
level)
{
- kvm_pte_t old = *ptep, pte = kvm_phys_to_pte(pa);
+ kvm_pte_t pte = kvm_phys_to_pte(pa);
u64 type = (level == KVM_PGTABLE_MAX_LEVELS - 1) ?
KVM_PTE_TYPE_PAGE :
KVM_PTE_TYPE_BLOCK;
@@ -181,12 +182,7 @@ static bool kvm_set_valid_leaf_pte(kvm_pte_t
*ptep, u64 pa, kvm_pte_t attr,
pte |= FIELD_PREP(KVM_PTE_TYPE, type);
pte |= KVM_PTE_VALID;
- /* Tolerate KVM recreating the exact same mapping. */
- if (kvm_pte_valid(old))
- return old == pte;
-
- smp_store_release(ptep, pte);
- return true;
+ return pte;
}
static int kvm_pgtable_visitor_cb(struct kvm_pgtable_walk_data
*data, u64 addr,
@@ -341,12 +337,17 @@ static int hyp_map_set_prot_attr(enum
kvm_pgtable_prot prot,
static bool hyp_map_walker_try_leaf(u64 addr, u64 end, u32 level,
kvm_pte_t *ptep, struct hyp_map_data *data)
{
+ kvm_pte_t new, old = *ptep;
u64 granule = kvm_granule_size(level), phys = data->phys;
if (!kvm_block_mapping_supported(addr, end, phys, level))
return false;
- WARN_ON(!kvm_set_valid_leaf_pte(ptep, phys, data->attr, level));
+ /* Tolerate KVM recreating the exact same mapping. */
+ new = kvm_init_valid_leaf_pte(phys, data->attr, level);
+ if (old != new && !WARN_ON(kvm_pte_valid(old)))
+ smp_store_release(ptep, new);
+
data->phys += granule;
return true;
}
@@ -461,25 +462,56 @@ static int stage2_map_set_prot_attr(enum
kvm_pgtable_prot prot,
return 0;
}
+static bool stage2_set_valid_leaf_pte_pre(u64 addr, u32 level,
+ kvm_pte_t *ptep, kvm_pte_t new,
+ struct stage2_map_data *data)
+{
+ kvm_pte_t old = *ptep, old_attr, new_attr;
+
+ if ((old ^ new) & (~KVM_PTE_LEAF_ATTR_PERMS))
+
Re: [RFC PATCH] KVM: arm64: Add prejudgement for relaxing permissions only case in stage2 translation fault handler
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 same GPA could occur
successively almost at the same time. There are two reasons for it.
(1) If there are some vCPUs accessing the same GPA at the same time
and the leaf PTE is not set yet, then they will all cause translation
faults and the first vCPU holding mmu_lock will set valid leaf PTE,
and the others will later choose to update the leaf PTE or not.
(2) When changing a leaf entry or a table entry with break-before-make,
if there are some vCPUs accessing the same GPA just catch the moment
when the target PTE is set invalid in a BBM procedure coincidentally,
they will all cause translation faults and will later choose to update
the leaf PTE or not.
The worst case can be like this: some vCPUs cause translation faults
on the same GPA with different prots, they will fight each other by
changing back access permissions of the PTE with break-before-make.
And the BBM-invalid moment might trigger more unnecessary translation
faults. As a result, some useless small loops will occur, which could
lead to vCPU stuck.
To avoid unnecessary update and small loops, add prejudgement in the
translation fault handler: Skip updating the valid leaf PTE if we are
trying to recreate exactly the same mapping or to reduce access
permissions only(such as RW-->RO). And update the valid leaf PTE without
break-before-make if we are trying to add more permissions only.
Signed-off-by: Yanan Wang
---
arch/arm64/kvm/hyp/pgtable.c | 73 +---
1 file changed, 52 insertions(+), 21 deletions(-)
Cheers for this. Given that this patch is solving a few different problems,
do you think you could split it up please? That would certainly make it much
easier to review, as there's quite a lot going on here. A chunk of the
changes seem to be the diff I posted previously:
https://lore.kernel.org/r/20201201141632.GC26973@willie-the-truck
so maybe that could be its own patch?
Yeah, I will split the diff into two patches at next version, thanks.
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index 23a01dfcb27a..f8b3248cef1c 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -45,6 +45,8 @@
#define KVM_PTE_LEAF_ATTR_HI_S2_XN BIT(54)
+#define KVM_PTE_LEAF_ATTR_PERMS (GENMASK(7, 6) | BIT(54))
You only use this on the S2 path, so how about:
#define KVM_PTE_LEAF_ATTR_S2_PERMS KVM_PTE_LEAF_ATTR_LO_S2_S2AP_R | \
KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W | \
KVM_PTE_LEAF_ATTR_HI_S2_XN
or something like that?
Yes, it's more reasonable.
struct kvm_pgtable_walk_data {
struct kvm_pgtable *pgt;
struct kvm_pgtable_walker *walker;
@@ -170,10 +172,9 @@ static void kvm_set_table_pte(kvm_pte_t *ptep, kvm_pte_t
*childp)
smp_store_release(ptep, pte);
}
-static bool kvm_set_valid_leaf_pte(kvm_pte_t *ptep, u64 pa, kvm_pte_t attr,
- u32 level)
+static kvm_pte_t kvm_init_valid_leaf_pte(u64 pa, kvm_pte_t attr, u32 level)
{
- kvm_pte_t old = *ptep, pte = kvm_phys_to_pte(pa);
+ kvm_pte_t pte = kvm_phys_to_pte(pa);
u64 type = (level == KVM_PGTABLE_MAX_LEVELS - 1) ? KVM_PTE_TYPE_PAGE :
KVM_PTE_TYPE_BLOCK;
@@ -181,12 +182,7 @@ static bool kvm_set_valid_leaf_pte(kvm_pte_t *ptep, u64 pa, kvm_pte_t attr,
pte |= FIELD_PREP(KVM_PTE_TYPE, type);
pte |= KVM_PTE_VALID;
- /* Tolerate KVM recreating the exact same mapping. */
- if (kvm_pte_valid(old))
- return old == pte;
-
- smp_store_release(ptep, pte);
- return true;
+ return pte;
}
static int kvm_pgtable_visitor_cb(struct kvm_pgtable_walk_data *data, u64 addr,
@@ -341,12 +337,17 @@ static int hyp_map_set_prot_attr(enum kvm_pgtable_prot
prot,
static bool hyp_map_walker_try_leaf(u64 addr, u64 end, u32 level,
kvm_pte_t *ptep, struct hyp_map_data *data)
{
+ kvm_pte_t new, old = *ptep;
u64 granule = kvm_granule_size(level), phys = data->phys;
if (!kvm_block_mapping_supported(addr, end, phys, level))
return false;
- WARN_ON(!kvm_set_valid_leaf_pte(ptep, phys, data->attr, level));
+ /* Tolerate KVM recreating the exact same mapping. */
+ new = kvm_init_valid_leaf_pte(phys, data->attr, level);
+ if (old != new && !WARN_ON(kvm_pte_valid(old)))
+ smp_store_release(ptep, new);
+
data->phys += granule;
return true;
}
@@ -461,25 +462,56 @@ static int stage2_map_set_prot_attr(enum kvm_pgtable_prot
prot,
Re: ping // [PATCH] mtd:cfi_cmdset_0002: fix atomic sleep bug when CONFIG_MTD_XIP=y
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 > b/drivers/mtd/chips/cfi_cmdset_0002.c > index a1f3e1031c3d..12c3776f093a 100644 > --- a/drivers/mtd/chips/cfi_cmdset_0002.c > +++ b/drivers/mtd/chips/cfi_cmdset_0002.c > @@ -1682,7 +1682,11 @@ static int __xipram > do_write_oneword_once(struct map_info *map, > set_current_state(TASK_UNINTERRUPTIBLE); > add_wait_queue(>wq, ); > mutex_unlock(>mutex); > + if (IS_ENABLED(CONFIG_MTD_XIP)) > + local_irq_enable(); > schedule(); > + if (IS_ENABLED(CONFIG_MTD_XIP)) > + local_irq_disable(); >>> >>> The fix really seems strange to me. I will let Vignesh decide but I >>> think we should consider updating/fixing xip_disable instead. >> >> Agree with Miquel. Have you done any testing >> or is this purely based on code inspection? >> > I don't have the corresponding device test environment. > I found the problem through code review. > Sorry, I am not comfortable applying this patch without proper testing that given the unknowns and legacy nature of the code. > >> What about comment before xip_disable() function: >> >> /* >> * No interrupt what so ever can be serviced while the flash isn't in >> array >> * mode. This is ensured by the xip_disable() and xip_enable() >> functions >> * enclosing any code path where the flash is known not to be in >> array mode. >> * And within a XIP disabled code path, only functions marked with >> __xipram >> * may be called and nothing else (it's a good thing to inspect >> generated >> * assembly to make sure inline functions were actually inlined and >> that gcc >> * didn't emit calls to its own support functions). Also configuring >> MTD CFI >> * support to a single buswidth and a single interleave is also >> recommended. >> */ >> >> So, I don't think the fix is as simple as this patch. >> > +xip_enable(); > schedule(); > +xip_disable(); > > Do I need to change it to this? > This just narrows the window, but an IRQ is still possible just after xip_enable() but before schedule(). Regards Vignesh
Re: [PATCH v2 04/10] regulator: bd9571mwv: Add BD9574MWF support
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 BD9574MWF which is silimar chip with BD9571MWV.
> > > Note that BD9574MWF doesn't support AVS and VID.
> >
> > I'd like to understand what is VID?
>
> It seems reading some voltages from registers.
> For example, BD9571 has "VD18_VID" register which
> is prohibit to write. But, BD9574 doesn't have this
> register. Also, the driver names "vid_ops",
> so I described "VID" here. Perhaps, we should revise
> the description to clear. (Please look "Updated description" in this
> email.)
Thank you for detailed explanation. So as far as I understood - VID is
a register which displays the current output voltage, right? If I am
not mistaken, this is different from register where (initial) voltage
is set?
>
> > > Signed-off-by: Yoshihiro Shimoda <
> > > yoshihiro.shimoda...@renesas.com>
> > > ---
> > > drivers/regulator/bd9571mwv-regulator.c | 10 --
> > > 1 file changed, 8 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/regulator/bd9571mwv-regulator.c
> > > b/drivers/regulator/bd9571mwv-regulator.c
> > > index 02120b0..041339b 100644
> > > --- a/drivers/regulator/bd9571mwv-regulator.c
> > > +++ b/drivers/regulator/bd9571mwv-regulator.c
> > > @@ -1,6 +1,6 @@
> > > // SPDX-License-Identifier: GPL-2.0
> > > /*
> > > - * ROHM BD9571MWV-M regulator driver
> > > + * ROHM BD9571MWV-M and BD9574MWF-M regulator driver
> > > *
> > > * Copyright (C) 2017 Marek Vasut > > >
> > > *
> > > @@ -9,6 +9,7 @@
> > > * NOTE: VD09 is missing
> > > */
> > >
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -277,6 +278,7 @@ static int bd9571mwv_regulator_probe(struct
> > > platform_device *pdev)
> > > struct regulator_dev *rdev;
> > > unsigned int val;
> > > int i;
> > > + enum rohm_chip_type chip = platform_get_device_id(pdev)-
> > > > driver_data;
> > >
> > > bdreg = devm_kzalloc(>dev, sizeof(*bdreg), GFP_KERNEL);
> > > if (!bdreg)
> > > @@ -292,6 +294,9 @@ static int bd9571mwv_regulator_probe(struct
> > > platform_device *pdev)
> > > config.regmap = bdreg->regmap;
> > >
> > > for (i = 0; i < ARRAY_SIZE(regulators); i++) {
> > > + /* BD9574MWF supports DVFS only */
> > > + if (chip == ROHM_CHIP_TYPE_BD9574 && regulators[i].id
> > > != DVFS)
> > > + continue;
> >
> > Does this mean that reading VD09 voltage is not supported by
> > driver?
>
> Yes. Also, reading VD{18,25,33} voltage are not supported.
I think that would be excellent comment here. Maybe something like: "We
don't support voltage rails VD{09,18,25,33} by this driver on BD9574."
>
> > (I
> > assumed VD09 initial voltage can be set from eeprom(?) and read by
> > driver - I may be wrong though). Perhaps it is worth mentioning in
> > the
> > commit message as a driver restriction?
>
> Yes, these voltage can be set from eeprom and read by driver.
> So, I updated the description like below.
>
> -- Updated description --
> Add support for BD9574MWF which is similar chip with BD9571MWV.
> Note that since BD9574MWF doesn't have avs_ops and vid_ops
> related registers, this driver avoids to use these registers
> if BD9574MWF is used.
>
Thank you :) What I was after is that I would like to leave a note
about 'what could be improved' or about what is the 'software
limitation' here so that if anyone later needs the other voltage rails
he would have a hint about what could be done.
Do you think mentioning that "the VD09 voltage could be read from PMIC
but that is not supported by this commit" in commit message would be
Ok?
>
> > And just asking out of the curiosity - are the other voltage rails
> > listed in data-sheet (VD18, DDR0, VD33, VD09 and LDO1,...,LDO4)
> > set-up
> > from DT as fixed-regulators? Any reason why they are not set-up
> > here?
>
> TBH, I don't know why. Perhaps, the driver cannot read DDR0, LDO[1-4]
> values?
I also think that all voltages can't be read. I was just thinking that
it might make sense to always create the fixed regulators from PMIC
driver - because if PMIC is used - then these voltage rails do exist.
(This was just a question so that I could learn - not so much of a
review comment.)
If you re-spin the series for other fixups - then I would appreciate
some comment about omitting the rest of the voltage outputs.
Other than that - for what it is worth:
Reviewed-by: Matti Vaittinen
Best Regards
Matti
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland
SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
"non cogito me" dixit Rene Descarte, deinde evanescavit
(Thanks for the translation
arch/arm64/kernel/entry-common.c:68:25: warning: no previous prototype for 'el1_sync_handler'
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 config: arm64-randconfig-r021-20201214 (attached as .config) compiler: aarch64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ed3768db588291ddb5dc794daed12cc751373566 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout ed3768db588291ddb5dc794daed12cc751373566 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): >> arch/arm64/kernel/entry-common.c:68:25: warning: no previous prototype for >> 'el1_sync_handler' [-Wmissing-prototypes] 68 | asmlinkage void notrace el1_sync_handler(struct pt_regs *regs) | ^~~~ vim +/el1_sync_handler +68 arch/arm64/kernel/entry-common.c 67 > 68 asmlinkage void notrace el1_sync_handler(struct pt_regs *regs) --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: mmc: atmel-mci: Reduce scope for the variable “slot” in atmci_request_end()
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 the function... I don't have a well developed philosophy for when variables should be declared with a smaller scope. int ret; <-- this should always be function scope Probably the other people are right that making scopes shorter is more important when the function is very long. regards, dan carpenter
Re: [RFC PATCH v3 1/2] block: add simple copy support
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 = bdev_get_queue(bdev);
> > + struct bio *bio;
> > + void *buf = NULL;
> > + int i, nr_srcs, max_range_len, ret, cur_dest, cur_size;
> > +
> > + nr_srcs = payload->copy_range;
> > + max_range_len = q->limits.max_copy_range_sectors << SECTOR_SHIFT;
> > + cur_dest = payload->dest;
> > + buf = kvmalloc(max_range_len, GFP_ATOMIC);
>
> Why GFP_ATOMIC and not the passed in gfp_mask? Especially as this is a
> kvmalloc()
> which has the potential to grow quite big.
>
> > +int __blkdev_issue_copy(struct block_device *bdev, sector_t dest,
> > + sector_t nr_srcs, struct range_entry *rlist, gfp_t gfp_mask,
> > + int flags, struct bio **biop)
> > +{
>
> [...]
>
> > + total_size = struct_size(payload, range, nr_srcs);
> > + payload = kmalloc(total_size, GFP_ATOMIC | __GFP_NOWARN);
>
> Same here.
>
>
> > diff --git a/block/ioctl.c b/block/ioctl.c
> > index 6b785181344f..a4a507d85e56 100644
> > --- a/block/ioctl.c
> > +++ b/block/ioctl.c
> > @@ -142,6 +142,47 @@ static int blk_ioctl_discard(struct block_device
> > *bdev, fmode_t mode,
> > GFP_KERNEL, flags);
> > }
> >
> > +static int blk_ioctl_copy(struct block_device *bdev, fmode_t mode,
> > + unsigned long arg, unsigned long flags)
> > +{
>
> [...]
>
> > +
> > + rlist = kmalloc_array(crange.nr_range, sizeof(*rlist),
> > + GFP_ATOMIC | __GFP_NOWARN);
>
> And here. I think this one can even be GFP_KERNEL.
>
>
>
Thanks. Will fix this.
Re: [PATCH v2 3/5] lazy tlb: shoot lazies, a non-refcounting lazy tlb option
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 > + depends on !MMU_LAZY_TLB_SHOOTDOWN > help > - This must be enabled if MMU_LAZY_TLB is enabled until the next > - patch. > + This refcounts the mm that is used as the lazy TLB mm when switching > + switching to a kernel thread. duplicate "switching". > + > +config MMU_LAZY_TLB_SHOOTDOWN > + bool > + depends on MMU_LAZY_TLB > + help > + Instead of refcounting the "lazy tlb" mm struct, which can cause > + contention with multi-threaded apps on large multiprocessor systems, > + this option causes __mmdrop to IPI all CPUs in the mm_cpumask and > + switch to init_mm if they were using the to-be-freed mm as the lazy > + tlb. To implement this, architectures must use _lazy_tlb variants of > + mm refcounting, and mm_cpumask must include at least all possible > + CPUs in which mm might be lazy. > > config ARCH_HAVE_NMI_SAFE_CMPXCHG > bool --
Re: [PATCH] soc: ti: k3-ringacc: Use correct error casting in k3_ringacc_dmarings_init
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
[PATCH v2 4/5] powerpc: use lazy mm refcount helper functions
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 8c2857cbd960..93c0eaa6f4bf 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -1395,7 +1395,7 @@ void start_secondary(void *unused)
{
unsigned int cpu = raw_smp_processor_id();
- mmgrab(_mm);
+ mmgrab_lazy_tlb(_mm);
current->active_mm = _mm;
smp_store_cpu_info(cpu);
--
2.23.0
[PATCH v2 5/5] powerpc/64s: enable MMU_LAZY_TLB_SHOOTDOWN
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 Piggin --- arch/powerpc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 5181872f9452..356138bdb5bb 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -232,6 +232,7 @@ config PPC select HAVE_PERF_USER_STACK_DUMP select MMU_GATHER_RCU_TABLE_FREE select MMU_GATHER_PAGE_SIZE + select MMU_LAZY_TLB_SHOOTDOWN if PPC_BOOK3S_64 select HAVE_REGS_AND_STACK_ACCESS_API select HAVE_RELIABLE_STACKTRACE if PPC_BOOK3S_64 && CPU_LITTLE_ENDIAN select HAVE_SYSCALL_TRACEPOINTS -- 2.23.0
[PATCH v2 2/5] lazy tlb: allow lazy tlb mm switching to be configurable
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 been switched over by default because the arch code needs
to be audited and tested for lazy tlb mm refcounting and converted
to _lazy_tlb refcounting if necessary.
CONFIG_MMU_LAZY_TLB_REFCOUNT is also added, but it must always
be enabled if CONFIG_MMU_LAZY_TLB is enabled until the next patch
which provides an alternate scheme.
Signed-off-by: Nicholas Piggin
---
arch/Kconfig | 17 +
include/linux/sched/mm.h | 13 +--
kernel/sched/core.c | 75 ++--
kernel/sched/sched.h | 4 ++-
4 files changed, 87 insertions(+), 22 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index ba4e966484ab..84faaba66364 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -430,6 +430,23 @@ config ARCH_WANT_IRQS_OFF_ACTIVATE_MM
irqs disabled over activate_mm. Architectures that do IPI based TLB
shootdowns should enable this.
+# Should make this depend on MMU, because there is little use for lazy mm
switching
+# with NOMMU. Must audit NOMMU architecture code for lazy mm refcounting first.
+config MMU_LAZY_TLB
+ def_bool y
+ help
+ Enable "lazy TLB" mmu context switching for kernel threads.
+ If this is disabled then switching to a kernel thread always
+ switches to init_mm. If mm switches are inexpensive or free
+ (in the case of NOMMU) then this could be disabled.
+
+config MMU_LAZY_TLB_REFCOUNT
+ def_bool y
+ depends on MMU_LAZY_TLB
+ help
+ This must be enabled if MMU_LAZY_TLB is enabled until the next
+ patch.
+
config ARCH_HAVE_NMI_SAFE_CMPXCHG
bool
diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
index 94a117160083..5edf8e942c84 100644
--- a/include/linux/sched/mm.h
+++ b/include/linux/sched/mm.h
@@ -52,12 +52,21 @@ static inline void mmdrop(struct mm_struct *mm)
/* Helpers for lazy TLB mm refcounting */
static inline void mmgrab_lazy_tlb(struct mm_struct *mm)
{
- mmgrab(mm);
+ if (IS_ENABLED(CONFIG_MMU_LAZY_TLB_REFCOUNT))
+ mmgrab(mm);
}
static inline void mmdrop_lazy_tlb(struct mm_struct *mm)
{
- mmdrop(mm);
+ if (IS_ENABLED(CONFIG_MMU_LAZY_TLB_REFCOUNT)) {
+ mmdrop(mm);
+ } else {
+ /*
+* mmdrop_lazy_tlb must provide a full memory barrier, see the
+* membarrier comment finish_task_switch which relies on this.
+*/
+ smp_mb();
+ }
}
/**
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c2f8ea43d29b..9c1dc9406e4b 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3579,7 +3579,7 @@ static struct rq *finish_task_switch(struct task_struct
*prev)
__releases(rq->lock)
{
struct rq *rq = this_rq();
- struct mm_struct *mm = rq->prev_mm;
+ struct mm_struct *mm = NULL;
long prev_state;
/*
@@ -3598,7 +3598,10 @@ static struct rq *finish_task_switch(struct task_struct
*prev)
current->comm, current->pid, preempt_count()))
preempt_count_set(FORK_PREEMPT_COUNT);
- rq->prev_mm = NULL;
+#ifdef CONFIG_MMU_LAZY_TLB_REFCOUNT
+ mm = rq->prev_lazy_mm;
+ rq->prev_lazy_mm = NULL;
+#endif
/*
* A task struct has one reference for the use as "current".
@@ -3722,22 +3725,10 @@ asmlinkage __visible void schedule_tail(struct
task_struct *prev)
calculate_sigpending();
}
-/*
- * context_switch - switch to the new MM and the new thread's register state.
- */
-static __always_inline struct rq *
-context_switch(struct rq *rq, struct task_struct *prev,
- struct task_struct *next, struct rq_flags *rf)
+static __always_inline void
+context_switch_mm(struct rq *rq, struct task_struct *prev,
+ struct task_struct *next)
{
- prepare_task_switch(rq, prev, next);
-
- /*
-* For paravirt, this is coupled with an exit in switch_to to
-* combine the page table reload and the switch backend into
-* one hypercall.
-*/
- arch_start_context_switch(prev);
-
/*
* kernel -> kernel lazy + transfer active
* user -> kernel lazy + mmgrab_lazy_tlb() active
@@ -3766,11 +3757,57 @@ context_switch(struct rq *rq, struct task_struct *prev,
switch_mm_irqs_off(prev->active_mm, next->mm, next);
if (!prev->mm) {// from kernel
- /* will mmdrop_lazy_tlb() in finish_task_switch(). */
- rq->prev_mm = prev->active_mm;
+#ifdef CONFIG_MMU_LAZY_TLB_REFCOUNT
+ /* Will
[PATCH v2 3/5] lazy tlb: shoot lazies, a non-refcounting lazy tlb option
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 instead implement a non-refcounted scheme
that causes __mmdrop() to IPI all CPUs in the mm_cpumask and shoot down
any remaining lazy ones.
Shootdown IPIs are some concern, but they have not been observed to be
a big problem with this scheme (the powerpc implementation generated
314 additional interrupts on a 144 CPU system during a kernel compile).
There are a number of strategies that could be employed to reduce IPIs
if they turn out to be a problem for some workload.
Signed-off-by: Nicholas Piggin
---
arch/Kconfig | 17 +++--
kernel/fork.c | 52 +++
2 files changed, 67 insertions(+), 2 deletions(-)
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
+ depends on !MMU_LAZY_TLB_SHOOTDOWN
help
- This must be enabled if MMU_LAZY_TLB is enabled until the next
- patch.
+ This refcounts the mm that is used as the lazy TLB mm when switching
+ switching to a kernel thread.
+
+config MMU_LAZY_TLB_SHOOTDOWN
+ bool
+ depends on MMU_LAZY_TLB
+ help
+ Instead of refcounting the "lazy tlb" mm struct, which can cause
+ contention with multi-threaded apps on large multiprocessor systems,
+ this option causes __mmdrop to IPI all CPUs in the mm_cpumask and
+ switch to init_mm if they were using the to-be-freed mm as the lazy
+ tlb. To implement this, architectures must use _lazy_tlb variants of
+ mm refcounting, and mm_cpumask must include at least all possible
+ CPUs in which mm might be lazy.
config ARCH_HAVE_NMI_SAFE_CMPXCHG
bool
diff --git a/kernel/fork.c b/kernel/fork.c
index 6d266388d380..74b972d2d8a9 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -669,6 +669,53 @@ static void check_mm(struct mm_struct *mm)
#define allocate_mm() (kmem_cache_alloc(mm_cachep, GFP_KERNEL))
#define free_mm(mm)(kmem_cache_free(mm_cachep, (mm)))
+static void do_shoot_lazy_tlb(void *arg)
+{
+ struct mm_struct *mm = arg;
+
+ if (current->active_mm == mm) {
+ WARN_ON_ONCE(current->mm);
+ current->active_mm = _mm;
+ switch_mm(mm, _mm, current);
+ }
+}
+
+static void do_check_lazy_tlb(void *arg)
+{
+ struct mm_struct *mm = arg;
+
+ WARN_ON_ONCE(current->active_mm == mm);
+}
+
+static void shoot_lazy_tlbs(struct mm_struct *mm)
+{
+ if (IS_ENABLED(CONFIG_MMU_LAZY_TLB_SHOOTDOWN)) {
+ /*
+* IPI overheads have not found to be expensive, but they could
+* be reduced in a number of possible ways, for example (in
+* roughly increasing order of complexity):
+* - A batch of mms requiring IPIs could be gathered and freed
+* at once.
+* - CPUs could store their active mm somewhere that can be
+* remotely checked without a lock, to filter out
+* false-positives in the cpumask.
+* - After mm_users or mm_count reaches zero, switching away
+* from the mm could clear mm_cpumask to reduce some IPIs
+* (some batching or delaying would help).
+* - A delayed freeing and RCU-like quiescing sequence based on
+* mm switching to avoid IPIs completely.
+*/
+ on_each_cpu_mask(mm_cpumask(mm), do_shoot_lazy_tlb, (void *)mm,
1);
+ if (IS_ENABLED(CONFIG_DEBUG_VM))
+ on_each_cpu(do_check_lazy_tlb, (void *)mm, 1);
+ } else {
+ /*
+* In this case, lazy tlb mms are refounted and would not reach
+* __mmdrop until all CPUs have switched away and mmdrop()ed.
+*/
+ }
+}
+
/*
* Called when the last reference to the mm
* is dropped: either by a lazy thread or by
@@ -678,7 +725,12 @@ void __mmdrop(struct mm_struct *mm)
{
BUG_ON(mm == _mm);
WARN_ON_ONCE(mm == current->mm);
+
+ /* Ensure no CPUs are using this as their lazy tlb mm */
+ shoot_lazy_tlbs(mm);
+
WARN_ON_ONCE(mm == current->active_mm);
+
mm_free_pgd(mm);
destroy_context(mm);
mmu_notifier_subscriptions_destroy(mm);
--
2.23.0
[PATCH v2 1/5] lazy tlb: introduce lazy mm refcount helper functions
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 ++--
fs/exec.c| 4 ++--
include/linux/sched/mm.h | 11 +++
kernel/cpu.c | 2 +-
kernel/exit.c| 2 +-
kernel/kthread.c | 11 +++
kernel/sched/core.c | 15 ---
8 files changed, 33 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-rpc/ecard.c b/arch/arm/mach-rpc/ecard.c
index 827b50f1c73e..1b4a41aad793 100644
--- a/arch/arm/mach-rpc/ecard.c
+++ b/arch/arm/mach-rpc/ecard.c
@@ -253,7 +253,7 @@ static int ecard_init_mm(void)
current->mm = mm;
current->active_mm = mm;
activate_mm(active_mm, mm);
- mmdrop(active_mm);
+ mmdrop_lazy_tlb(active_mm);
ecard_init_pgtables(mm);
return 0;
}
diff --git a/arch/powerpc/mm/book3s64/radix_tlb.c
b/arch/powerpc/mm/book3s64/radix_tlb.c
index b487b489d4b6..74708aef333e 100644
--- a/arch/powerpc/mm/book3s64/radix_tlb.c
+++ b/arch/powerpc/mm/book3s64/radix_tlb.c
@@ -658,10 +658,10 @@ static void do_exit_flush_lazy_tlb(void *arg)
if (current->active_mm == mm) {
WARN_ON_ONCE(current->mm != NULL);
/* Is a kernel thread and is using mm as the lazy tlb */
- mmgrab(_mm);
+ mmgrab_lazy_tlb(_mm);
current->active_mm = _mm;
switch_mm_irqs_off(mm, _mm, current);
- mmdrop(mm);
+ mmdrop_lazy_tlb(mm);
}
atomic_dec(>context.active_cpus);
diff --git a/fs/exec.c b/fs/exec.c
index 547a2390baf5..56fc23dcbe4d 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1028,9 +1028,9 @@ static int exec_mmap(struct mm_struct *mm)
setmax_mm_hiwater_rss(>signal->maxrss, old_mm);
mm_update_next_owner(old_mm);
mmput(old_mm);
- return 0;
+ } else {
+ mmdrop_lazy_tlb(active_mm);
}
- mmdrop(active_mm);
return 0;
}
diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
index d5ece7a9a403..94a117160083 100644
--- a/include/linux/sched/mm.h
+++ b/include/linux/sched/mm.h
@@ -49,6 +49,17 @@ static inline void mmdrop(struct mm_struct *mm)
__mmdrop(mm);
}
+/* Helpers for lazy TLB mm refcounting */
+static inline void mmgrab_lazy_tlb(struct mm_struct *mm)
+{
+ mmgrab(mm);
+}
+
+static inline void mmdrop_lazy_tlb(struct mm_struct *mm)
+{
+ mmdrop(mm);
+}
+
/**
* mmget() - Pin the address space associated with a mm_struct.
* @mm: The address space to pin.
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 2b8d7a5db383..a54cdfa08d71 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -576,7 +576,7 @@ static int finish_cpu(unsigned int cpu)
*/
if (mm != _mm)
idle->active_mm = _mm;
- mmdrop(mm);
+ mmdrop_lazy_tlb(mm);
return 0;
}
diff --git a/kernel/exit.c b/kernel/exit.c
index 1f236ed375f8..3711a74fcf4a 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -474,7 +474,7 @@ static void exit_mm(void)
__set_current_state(TASK_RUNNING);
mmap_read_lock(mm);
}
- mmgrab(mm);
+ mmgrab_lazy_tlb(mm);
BUG_ON(mm != current->active_mm);
/* more a memory barrier than a real lock */
task_lock(current);
diff --git a/kernel/kthread.c b/kernel/kthread.c
index 933a625621b8..da189e0d26ed 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -1240,14 +1240,14 @@ void kthread_use_mm(struct mm_struct *mm)
WARN_ON_ONCE(!(tsk->flags & PF_KTHREAD));
WARN_ON_ONCE(tsk->mm);
+ mmgrab(mm);
+
task_lock(tsk);
/* Hold off tlb flush IPIs while switching mm's */
local_irq_disable();
active_mm = tsk->active_mm;
- if (active_mm != mm) {
- mmgrab(mm);
+ if (active_mm != mm)
tsk->active_mm = mm;
- }
tsk->mm = mm;
switch_mm_irqs_off(active_mm, mm, tsk);
local_irq_enable();
@@ -1257,7 +1257,7 @@ void kthread_use_mm(struct mm_struct *mm)
#endif
if (active_mm != mm)
- mmdrop(active_mm);
+ mmdrop_lazy_tlb(active_mm);
to_kthread(tsk)->oldfs = force_uaccess_begin();
}
@@ -1280,10 +1280,13 @@ void kthread_unuse_mm(struct mm_struct *mm)
sync_mm_rss(mm);
local_irq_disable();
tsk->mm = NULL;
+ mmgrab_lazy_tlb(mm);
/* active_mm is still 'mm' */
enter_lazy_tlb(mm, tsk);
local_irq_enable();
task_unlock(tsk);
+
+ mmdrop(mm);
}
EXPORT_SYMBOL_GPL(kthread_unuse_mm);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index
Re: [RFC PATCH v3 1/2] block: add simple copy support
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 = bdev_get_queue(bdev);
> > + struct bio *bio;
> > + void *buf = NULL;
> > + int i, nr_srcs, max_range_len, ret, cur_dest, cur_size;
> > +
> > + nr_srcs = payload->copy_range;
> > + max_range_len = q->limits.max_copy_range_sectors << SECTOR_SHIFT;
>
> The default value for this limit is 0, and this is the function for when
> the device doesn't support copy. Are we expecting drivers to set this
> value to something else for that case?
Sorry. Missed that. Will add a fix.
>
> > + cur_dest = payload->dest;
> > + buf = kvmalloc(max_range_len, GFP_ATOMIC);
> > + if (!buf)
> > + return -ENOMEM;
> > +
> > + for (i = 0; i < nr_srcs; i++) {
> > + bio = bio_alloc(gfp_mask, 1);
> > + bio->bi_iter.bi_sector = payload->range[i].src;
> > + bio->bi_opf = REQ_OP_READ;
> > + bio_set_dev(bio, bdev);
> > +
> > + cur_size = payload->range[i].len << SECTOR_SHIFT;
> > + ret = bio_add_page(bio, virt_to_page(buf), cur_size,
> > +offset_in_page(payload));
>
> 'buf' is vmalloc'ed, so we don't necessarily have congituous pages. I
> think you need to allocate the bio with bio_map_kern() or something like
> that instead with that kind of memory.
>
Sure. Will use bio_map_kern().
> > + if (ret != cur_size) {
> > + ret = -ENOMEM;
> > + goto out;
> > + }
> > +
> > + ret = submit_bio_wait(bio);
> > + bio_put(bio);
> > + if (ret)
> > + goto out;
> > +
> > + bio = bio_alloc(gfp_mask, 1);
> > + bio_set_dev(bio, bdev);
> > + bio->bi_opf = REQ_OP_WRITE;
> > + bio->bi_iter.bi_sector = cur_dest;
> > + ret = bio_add_page(bio, virt_to_page(buf), cur_size,
> > +offset_in_page(payload));
> > + if (ret != cur_size) {
> > + ret = -ENOMEM;
> > + goto out;
> > + }
> > +
> > + ret = submit_bio_wait(bio);
> > + bio_put(bio);
> > + if (ret)
> > + goto out;
> > +
> > + cur_dest += payload->range[i].len;
> > + }
>
> I think this would be a faster implementation if the reads were
> asynchronous with a payload buffer allocated specific to that read, and
> the callback can enqueue the write part. This would allow you to
> accumulate all the read data and write it in a single call.
Sounds like a better approach. Will add this implementation in v4.
[PATCH] soc: ti: k3-ringacc: Use correct error casting in k3_ringacc_dmarings_init
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 https://lore.kernel.org/lkml/20201208090440.31792-1-peter.ujfal...@ti.com/ Regards, Peter drivers/soc/ti/k3-ringacc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soc/ti/k3-ringacc.c b/drivers/soc/ti/k3-ringacc.c index c88c305ba367..b495b0d5d0fa 100644 --- a/drivers/soc/ti/k3-ringacc.c +++ b/drivers/soc/ti/k3-ringacc.c @@ -1476,7 +1476,7 @@ struct k3_ringacc *k3_ringacc_dmarings_init(struct platform_device *pdev, res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ringrt"); base_rt = devm_ioremap_resource(dev, res); if (IS_ERR(base_rt)) - return base_rt; + return ERR_CAST(base_rt); ringacc->rings = devm_kzalloc(dev, sizeof(*ringacc->rings) * -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v2 0/5] shoot lazy tlbs
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 functions lazy tlb: allow lazy tlb mm switching to be configurable lazy tlb: shoot lazies, a non-refcounting lazy tlb option powerpc: use lazy mm refcount helper functions powerpc/64s: enable MMU_LAZY_TLB_SHOOTDOWN arch/Kconfig | 30 ++ arch/arm/mach-rpc/ecard.c| 2 +- arch/powerpc/Kconfig | 1 + arch/powerpc/kernel/smp.c| 2 +- arch/powerpc/mm/book3s64/radix_tlb.c | 4 +- fs/exec.c| 4 +- include/linux/sched/mm.h | 20 +++ kernel/cpu.c | 2 +- kernel/exit.c| 2 +- kernel/fork.c| 52 kernel/kthread.c | 11 ++-- kernel/sched/core.c | 88 kernel/sched/sched.h | 4 +- 13 files changed, 184 insertions(+), 38 deletions(-) -- 2.23.0
Re: [PATCH bpf-next 1/2] bpf: Add a bpf_kallsyms_lookup 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 with exception of \0 char. More meaningful names, etc. See Documentation/core-api/printk-formats.rst I agree this would be nice. I finally got a bit of time to experiment with this and I noticed a few things: First of all, because helpers only have 5 arguments, if we use two for the output buffer and its size and two for the format string and its size, we are only left with one argument for a modifier. This is still enough for our usecase (where we'd only use "%ps" for example) but it does not strictly-speaking allow for the same layout that Andrii proposed. See helper bpf_seq_printf. It packs all arguments for format string and puts them into an array. bpf_seq_printf will unpack them as it parsed through the format string. So it should be doable to have more than "%ps" in format string. If we force fmt to come from readonly map then bpf_trace_printk()-like run-time check of fmt string can be moved into load time check and performance won't suffer. Regarding this bit, I have the impression that this would not be possible, but maybe I'm missing something ? :) The iteration that bpf_trace_printk does over the format string argument is not only used for validation. It is also used to remember what extra operations need to be done based on the modifier types. For example, it remembers whether an arg should be interpreted as 32bits or 64bits. In the case of string printing, it also remembers whether it is a kernel-space or user-space pointer so that bpf_trace_copy_string can be called with the right arg. If we were to run the iteration over the format string in the verifier, how would you recommend that we "remember" the modifier type until the helper gets called ?
[PATCH v2 -next] leds: ss4200: simplify the return expression of register_nasgpio_led()
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
+++ b/drivers/leds/leds-ss4200.c
@@ -478,7 +478,6 @@ ATTRIBUTE_GROUPS(nasgpio_led);
static int register_nasgpio_led(int led_nr)
{
- int ret;
struct nasgpio_led *nas_led = _leds[led_nr];
struct led_classdev *led = get_classdev_for_led_nr(led_nr);
@@ -489,11 +488,8 @@ static int register_nasgpio_led(int led_nr)
led->brightness_set = nasgpio_led_set_brightness;
led->blink_set = nasgpio_led_set_blink;
led->groups = nasgpio_led_groups;
- ret = led_classdev_register(_gpio_pci_dev->dev, led);
- if (ret)
- return ret;
- return 0;
+ return led_classdev_register(_gpio_pci_dev->dev, led);
}
static void unregister_nasgpio_led(int led_nr)
--
2.22.0
RE: [PATCH v2 09/10] mfd: bd9571mwv: Make the driver more generic
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 the functions and data structure become more generic
> > so that it can support other PMIC variants as well.
> >
> > Signed-off-by: Khiem Nguyen
> > [shimoda: rebase and refactor]
> > Signed-off-by: Yoshihiro Shimoda
> > ---
> > drivers/mfd/bd9571mwv.c | 71
> > +++
> > include/linux/mfd/bd9571mwv.h | 18 ++-
> > 2 files changed, 62 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c
> > index 80c6ef0..adb9e3d 100644
> > --- a/drivers/mfd/bd9571mwv.c
> > +++ b/drivers/mfd/bd9571mwv.c
> > +struct bd9571mwv {
> > + struct device *dev;
> > + struct regmap *regmap;
> > + const struct bd957x_data *data;
> > +
> > + /* IRQ Data */
> > + int irq;
> > + struct regmap_irq_chip_data *irq_data;
> > +};
> > +
>
> I still don't see why you actually need this structure?
I'm sorry. I completely forgot that you said we can remove this
structure in the previous patch's review...
> > static const struct mfd_cell bd9571mwv_cells[] = {
> > { .name = "bd9571mwv-regulator", },
> > { .name = "bd9571mwv-gpio", },
> > @@ -102,6 +131,14 @@ static struct regmap_irq_chip bd9571mwv_irq_chip
> > = {
> > .num_irqs = ARRAY_SIZE(bd9571mwv_irqs),
> > };
> >
> > +static const struct bd957x_data bd9571mwv_data = {
> > + .part_name = BD9571MWV_PART_NAME,
> > + .regmap_config = _regmap_config,
> > + .irq_chip = _irq_chip,
> > + .cells = bd9571mwv_cells,
> > + .num_cells = ARRAY_SIZE(bd9571mwv_cells),
> > +};
> > +
> > static int bd9571mwv_identify(struct bd9571mwv *bd)
> > {
> > struct device *dev = bd->dev;
> > @@ -127,13 +164,6 @@ static int bd9571mwv_identify(struct bd9571mwv
> > *bd)
> > ret);
> > return ret;
> > }
> > -
> > - if (value != BD9571MWV_PRODUCT_CODE_VAL) {
> > - dev_err(dev, "Invalid product code ID %02x (expected
> > %02x)\n",
> > - value, BD9571MWV_PRODUCT_CODE_VAL);
> > - return -EINVAL;
> > - }
> > -
> > ret = regmap_read(bd->regmap, BD9571MWV_PRODUCT_REVISION,
> > );
> > if (ret) {
> > dev_err(dev, "Failed to read revision register
> > (ret=%i)\n",
> > @@ -141,7 +171,8 @@ static int bd9571mwv_identify(struct bd9571mwv
> > *bd)
> > return ret;
> > }
> >
> > - dev_info(dev, "Device: BD9571MWV rev. %d\n", value & 0xff);
> > + dev_info(dev, "Device: %s rev. %d\n", bd->data->part_name,
> > +value & 0xff);
> >
> > return 0;
> > }
> > @@ -160,7 +191,23 @@ static int bd9571mwv_probe(struct i2c_client
> > *client,
> > bd->dev = >dev;
> > bd->irq = client->irq;
> >
> > - bd->regmap = devm_regmap_init_i2c(client,
> > _regmap_config);
> > + /* Read the PMIC product code */
> > + ret = i2c_smbus_read_byte_data(client, BD9571MWV_PRODUCT_CODE);
> > + if (ret < 0) {
> > + dev_err(>dev, "failed reading at 0x%02x\n",
> > + BD9571MWV_PRODUCT_CODE);
> > + return ret;
> > + }
> > + switch (ret) {
> > + case BD9571MWV_PRODUCT_CODE_VAL:
> > + bd->data = _data;
> > + break;
> > + default:
> > + dev_err(bd->dev, "Unsupported device 0x%x\n", ret);
> > + return -ENOENT;
> > + }
> > +
> > + bd->regmap = devm_regmap_init_i2c(client, bd->data-
> > >regmap_config);
> > if (IS_ERR(bd->regmap)) {
> > dev_err(bd->dev, "Failed to initialize register
> > map\n");
> > return PTR_ERR(bd->regmap);
> > @@ -171,14 +218,14 @@ static int bd9571mwv_probe(struct i2c_client
> > *client,
> > return ret;
> >
> > ret = regmap_add_irq_chip(bd->regmap, bd->irq, IRQF_ONESHOT, 0,
> > - _irq_chip, >irq_data);
> > + bd->data->irq_chip, >irq_data);
>
> I think you already did the big task when you cleaned up the sub-
> drivers from using the struct bd9571mwv. Thumbs up for that!
>
> So, as I said in comment to previous version - I don't see this struct
> bd9571mwv being really used anywhere else but as an argument to IC
> identification function and argument for the remove. I think that by
> switching regmap_add_irq_chip to devm_regmap_add_irq_chip you could get
> rid of the remove, error cleanup path and the i2c_clientdata. And if
> you revised the arguments for identification function you could
> probably further clean the struct definitions.
Thank you for the detailed comments. I agreed we can simplify the code
if we use devm_regmap_add_irq_chip. Also, I found a bug in the current
code which we should call devm_mfd_add_devices() instead of
mfd_add_devices(). So, I'll make a fixed patch
Re: [PATCH v3 3/3] iio:Documentation: Add documentation for hinge sensor channels
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 +0800
> > > Ye Xiang wrote:
> > >
> > > > Add channel description for hinge sensor, including channel label
> > > > attribute and raw data description.
> > > >
> > > > Signed-off-by: Ye Xiang
> > > > ---
> > > > Documentation/ABI/testing/sysfs-bus-iio | 17 +
> > > > 1 file changed, 17 insertions(+)
> > > >
> > > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> > > > b/Documentation/ABI/testing/sysfs-bus-iio
> > > > index df42bed09f25..82303b1bdff0 100644
> > > > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > > > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > > > @@ -1802,3 +1802,20 @@ Contact: linux-...@vger.kernel.org
> > > > Description:
> > > > Unscaled light intensity according to CIE 1931/DIN 5033
> > > > color space.
> > > > Units after application of scale are nano nanowatts per
> > > > square meter.
> > > > +
> > > > +What: /sys/bus/iio/devices/iio:deviceX/in_anglY_raw
> > > > +KernelVersion: 5.12
> > > > +Contact: linux-...@vger.kernel.org
> > > > +Description:
> > > > + Angle of rotation for channel Y. Units after
> > > > application of scale
> > > > + and offset are radians.
> > >
> > > This entry is already mostly in the doc around line 200, just without the
> > > index.
> > > Please just add the What: line to that block to reduce repetition.
> > > If you want to add... "Where present, Y indexes the channel." or
> > > something like
> > > that feel free.
> > When adding in_anglY_raw to in_angl_raw block, Should I update the
> > KernelVersion form
> > 4.17 to 5.12? Like blow:
> >
> > What: /sys/bus/iio/devices/iio:deviceX/in_angl_raw
> > What: /sys/bus/iio/devices/iio:deviceX/in_anglY_raw
> > KernelVersion: 5.12
> > Contact:linux-...@vger.kernel.org
> > Description:
> > Angle of rotation. Units after application of scale and offset
> > are radians. Where present, Y indexes the channel.
>
> No. This is an unfortunate limitation of these files unless we keep
> duplicating
> nearly identical text.
>
> I'm not that worried about documenting an optional bit of ABI as apparently
> being in an earlier kernel than it actually was. That way any userspace
> will work. The other way around is more likely to cause problems.
Got it, then I will keep KernelVersion 4.17. will send the next version out
for review soon. Thanks again for the review.
>
> >
> > >
> > >
> > > > +
> > > > +What: /sys/bus/iio/devices/iio:deviceX/in_anglY_label
> > > > +KernelVersion: 5.12
> > > > +Contact: linux-...@vger.kernel.org
> > > > +Description:
> > > > + Optional symbolic label for channel Y.
> > > > + For Intel hid hinge sensor, the label values are:
> > > > + hinge, keyboard, screen. It means the three channels
> > > > + each correspond respectively to hinge angle, keyboard
> > > > angle,
> > > > + and screen angle.
> > >
> > > Makes sense to keep this block separate given the additional info
> > > provided.
> > > Alternative would be to add it to the one with in_voltageY_label which
> > > would
> > > be odd given what follows!
> > Ok, Then I will keep the in_anglY_label block here. BTW, I didnot see
> > in_voltageY_label
> > in sysfs-bus-iio in current kernel master branch.
> It was part of the series that added the support for per channel labels to
> the core.
> 3079188f821c ("iio:Documentation: Add documentation for label channel
> attribute")
> so will only going into current master in the merge window that will open
> shortly.
got it.
>
Thanks
Ye, Xiang
Re: [PATCH v2 0/6] kernfs: proposed locking and concurrency improvement
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 > > > > (https://lore.kernel.org/lkml/x8fe0cmu+aq1g...@mtj.duckdns.org/), > > > > maybe a global > > > > rwsem for kn->iattr will be better?? > > > > > > I wasn't sure about that, IIRC a spin lock could be used around the > > > initial check and checked again at the end which would probably > > > have > > > been much faster but much less conservative and a bit more ugly so > > > I just went the conservative path since there was so much change > > > already. > > > > Sorry, I hadn't looked at Tejun's reply yet and TBH didn't remember > > it. > > > > Based on what Tejun said it sounds like that needs work. > > Those attribute handling patches were meant to allow taking the rw > sem read lock instead of the write lock for kernfs_refresh_inode() > updates, with the added locking to protect the inode attributes > update since it's called from the VFS both with and without the > inode lock. Oh, understood. I was asking also because lock on kn->attr_mutex drags concurrent performance. > Looking around it looks like kernfs_iattrs() is called from multiple > places without a node database lock at all. > > I'm thinking that, to keep my proposed change straight forward > and on topic, I should just leave kernfs_refresh_inode() taking > the node db write lock for now and consider the attributes handling > as a separate change. Once that's done we could reconsider what's > needed to use the node db read lock in kernfs_refresh_inode(). You meant taking write lock of kernfs_rwsem for kernfs_refresh_inode()?? It may be a lot slower in my benchmark, let me test it. > It will reduce the effectiveness of the series but it would make > this change much more complicated, and is somewhat off-topic, and > could hamper the chances of reviewers spotting problem with it. > > Ian > thanks, fox
Re: linux-next: build failure after merge of the watchdog tree
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 drivers/watchdog/iTCO_wdt.c:48:
> drivers/watchdog/iTCO_wdt.c: In function 'iTCO_wdt_start':
> drivers/watchdog/iTCO_wdt.c:280:17: error: 'struct watchdog_device' has no
> member named 'dev'
> 280 | dev_err(wd_dev->dev, "failed to reset NO_REBOOT flag, reboot
> disabled by hardware/BIOS\n");
> | ^~
Yes, that should have been wd_dev->parent. Sorry I didn't notice that earlier.
Guenter
> include/linux/dev_printk.h:112:11: note: in definition of macro 'dev_err'
> 112 | _dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
> | ^~~
>
> Caused by commit
>
> 9c612b338fdf ("watchdog: iTCO_wdt: use dev_*() instead of pr_*() for
> logging")
>
> I have used the wtchdog tree from next-20201211 for today.
>
signature.asc
Description: OpenPGP digital signature
[PATCH] ALSA: hda: Enable runtime PM when codec probe fails
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 let graphics card be
able to runtime suspend again.
Merge azx_probe_continue() into azx_probe() and just let probe fail for
this case could be a better approach. However that's a much bigger task
so let's settle with a quirk workaround.
BugLink: https://bugs.launchpad.net/bugs/1907212
Signed-off-by: Kai-Heng Feng
---
sound/pci/hda/hda_intel.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 6852668f1bcb..3fd920069268 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2328,7 +2328,7 @@ static int azx_probe_continue(struct azx *chip)
if (bus->codec_mask) {
err = azx_probe_codecs(chip, azx_max_codecs[chip->driver_type]);
if (err < 0)
- goto out_free;
+ goto out_enable_rpm;
}
#ifdef CONFIG_SND_HDA_PATCH_LOADER
@@ -2360,6 +2360,7 @@ static int azx_probe_continue(struct azx *chip)
set_default_power_save(chip);
+out_enable_rpm:
if (azx_has_pm_runtime(chip)) {
pm_runtime_use_autosuspend(>dev);
pm_runtime_allow(>dev);
--
2.29.2
Re: [PATCH] drivers: block: skd: remove skd_pci_info()
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:
[8.509243] pci :d8:00.0: [1b39:0001] type 00 class 0x018000
[8.515933] pci :d8:00.0: reg 0x10: [mem 0xfbe0-0xfbe0]
[8.521924] pci :d8:00.0: reg 0x14: [mem 0xfbe1-0xfbe10fff]
[8.527957] pci :d8:00.0: reg 0x30: [mem 0xfbd0-0xfbdf
pref]
[8.534999] pci :d8:00.0: supports D1 D2
No link speed. Checking the code, I think you need to actually call
pcie_print_link_status() (which calls __pcie_print_link_status() with
verbose = true) from the driver to see anything. Otherwise, the PCIe
core will not print anything if the driver is just probing and getting
resources for the card.
>
> Signed-off-by: Puranjay Mohan
> ---
> drivers/block/skd_main.c | 31 ---
> 1 file changed, 31 deletions(-)
>
> diff --git a/drivers/block/skd_main.c b/drivers/block/skd_main.c
> index a962b4551bed..da7aac5335d9 100644
> --- a/drivers/block/skd_main.c
> +++ b/drivers/block/skd_main.c
[...]
> static int skd_pci_probe(struct pci_dev *pdev, const struct pci_device_id
> *ent)
> {
> int i;
> int rc = 0;
> - char pci_str[32];
> struct skd_device *skdev;
>
> dev_dbg(>dev, "vendor=%04X device=%04x\n", pdev->vendor,
> @@ -3201,8 +3172,6 @@ static int skd_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> goto err_out_regions;
> }
>
> - skd_pci_info(skdev, pci_str);
> - dev_info(>dev, "%s 64bit\n", pci_str);
Replace these 2 lines with:
pcie_print_link_status(pdev);
And the link speed information will be printed.
--
Damien Le Moal
Western Digital Research
Re: [PATCH -next] md/bcache: convert comma to semicolon
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(-) > > diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c > index 554e3afc9b68..00a520c03f41 100644 > --- a/drivers/md/bcache/sysfs.c > +++ b/drivers/md/bcache/sysfs.c > @@ -404,7 +404,7 @@ STORE(__cached_dev) > if (!env) > return -ENOMEM; > add_uevent_var(env, "DRIVER=bcache"); > - add_uevent_var(env, "CACHED_UUID=%pU", dc->sb.uuid), > + add_uevent_var(env, "CACHED_UUID=%pU", dc->sb.uuid); > add_uevent_var(env, "CACHED_LABEL=%s", buf); > kobject_uevent_env(_to_dev(dc->disk.disk)->kobj, > KOBJ_CHANGE, >
[PATCH v3 1/4] spi: LS7A: Add Loongson LS7A SPI controller driver support
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 programmable polarity and phase
- SPI can be controlled in wait mode
- Support boot from SPI
Use mtd_debug tool to earse/write/read /dev/mtd0 on development.
eg:
[root@linux mtd-utils-1.0.0]# mtd_debug erase /dev/mtd0 0x2 0x4
Erased 262144 bytes from address 0x0002 in flash
[root@linux mtd-utils-1.0.0]# mtd_debug write /dev/mtd0 0x2 13 1.img
Copied 13 bytes from 1.img to address 0x0002 in flash
[root@linux mtd-utils-1.0.0]# mtd_debug read /dev/mtd0 0x2 13 2.img
Copied 13 bytes from address 0x0002 in flash to 2.img
[root@linux mtd-utils-1.0.0]# cmp -l 1.img 2.img
Signed-off-by: Juxin Gao
Signed-off-by: Qing Zhang
---
v2:
- keep Kconfig and Makefile sorted
- make the entire comment a C++ one so things look more intentional
- Fix unclear indentation
- make conditional statements to improve legibility
- Don't use static inline
- the core handle message queue
- Add a new binding document
- Fix probe part mixed pdev and PCI
v3:
- expose set_cs to the core and let it handle things
- replace transfer_one_message to transfer_one
- replace spi_alloc_master to devm_spi_alloc_master
- split out into prepare/unprepare_message
- releases pci regions before unregister master
---
drivers/spi/Kconfig| 7 ++
drivers/spi/Makefile | 1 +
drivers/spi/spi-ls7a.c | 293 +
3 files changed, 301 insertions(+)
create mode 100644 drivers/spi/spi-ls7a.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index aadaea0..af7c0d4 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -413,6 +413,13 @@ config SPI_LP8841_RTC
Say N here unless you plan to run the kernel on an ICP DAS
LP-8x4x industrial computer.
+config SPI_LS7A
+ tristate "Loongson LS7A SPI Controller Support"
+ depends on CPU_LOONGSON64 || COMPILE_TEST
+ help
+ This drivers supports the Loongson LS7A SPI controller in master
+ SPI mode.
+
config SPI_MPC52xx
tristate "Freescale MPC52xx SPI (non-PSC) controller support"
depends on PPC_MPC52xx
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 6fea582..d015cf2 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_SPI_LANTIQ_SSC) += spi-lantiq-ssc.o
obj-$(CONFIG_SPI_JCORE)+= spi-jcore.o
obj-$(CONFIG_SPI_LM70_LLP) += spi-lm70llp.o
obj-$(CONFIG_SPI_LP8841_RTC) += spi-lp8841-rtc.o
+obj-$(CONFIG_SPI_LS7A) += spi-ls7a.o
obj-$(CONFIG_SPI_MESON_SPICC) += spi-meson-spicc.o
obj-$(CONFIG_SPI_MESON_SPIFC) += spi-meson-spifc.o
obj-$(CONFIG_SPI_MPC512x_PSC) += spi-mpc512x-psc.o
diff --git a/drivers/spi/spi-ls7a.c b/drivers/spi/spi-ls7a.c
new file mode 100644
index 000..d3b7e86
--- /dev/null
+++ b/drivers/spi/spi-ls7a.c
@@ -0,0 +1,293 @@
+// SPDX-License-Identifier: GPL-2.0-only
+//
+// Loongson LS7A SPI Controller driver
+//
+// Copyright (C) 2020 Loongson Technology Corporation Limited.
+//
+
+#include
+#include
+#include
+
+/* define spi register */
+#defineSPCR0x00
+#defineSPSR0x01
+#defineFIFO0x02
+#defineSPER0x03
+#definePARA0x04
+#defineSFCS0x05
+#defineTIMI0x06
+
+struct ls7a_spi {
+ spinlock_t lock;
+ struct spi_master *master;
+ void __iomem *base;
+ unsigned int hz;
+ unsigned char spcr, sper;
+ unsigned int mode;
+};
+
+static void ls7a_spi_write_reg(struct ls7a_spi *spi,
+ unsigned char reg,
+ unsigned char data)
+{
+ writeb(data, spi->base + reg);
+}
+
+static char ls7a_spi_read_reg(struct ls7a_spi *spi, unsigned char reg)
+{
+ return readb(spi->base + reg);
+}
+
+static int ls7a_spi_prepare_message(struct spi_master *master,
+ struct spi_message *msg)
+{
+ struct ls7a_spi *ls7a_spi;
+ int param;
+
+ ls7a_spi = spi_master_get_devdata(master);
+
+ spin_lock(_spi->lock);
+ param = ls7a_spi_read_reg(ls7a_spi, PARA);
+ ls7a_spi_write_reg(ls7a_spi, PARA, param &= ~1);
+ spin_unlock(_spi->lock);
+
+ return 0;
+}
+
+static int ls7a_spi_unprepare_message(struct spi_master *master,
+ struct spi_message *msg)
+{
+ struct ls7a_spi *ls7a_spi;
+ int param = 0;
+
+ ls7a_spi = spi_master_get_devdata(master);
+
+ spin_lock(_spi->lock);
+ ls7a_spi_write_reg(ls7a_spi, PARA, param);
+ spin_unlock(_spi->lock);
+
+ return 0;
+}
+
+static void ls7a_spi_set_cs(struct spi_device
[PATCH v3 3/4] MIPS: Loongson64: DTS: Add SPI support to LS7A
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
b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
index f99a7a1..d91857c 100644
--- a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
+++ b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
@@ -405,6 +405,18 @@
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 39
IRQ_TYPE_LEVEL_HIGH>;
};
+
+ spi@16,0 {
+ compatible = "pci0014,7a0b.0",
+ "pci0014,7a0b",
+ "pciclass088000",
+ "pciclass0880";
+
+ reg = <0xb000 0x0 0x0 0x0 0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ num-chipselects = <0>;
+ };
};
isa {
--
2.1.0
[PATCH v3 4/4] MIPS: Loongson: Enable Loongson LS7A SPI in loongson3_defconfig
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 b/arch/mips/configs/loongson3_defconfig index 38a817e..28784cb 100644 --- a/arch/mips/configs/loongson3_defconfig +++ b/arch/mips/configs/loongson3_defconfig @@ -271,6 +271,9 @@ CONFIG_HW_RANDOM=y CONFIG_RAW_DRIVER=m CONFIG_I2C_CHARDEV=y CONFIG_I2C_PIIX4=y +CONFIG_SPI=y +CONFIG_SPI_MASTER=y +CONFIG_SPI_LS7A=y CONFIG_GPIO_LOONGSON=y CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM93=m -- 2.1.0
[PATCH v3 2/4] spi: ls7a: Add YAML schemas
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
diff --git a/Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
b/Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
new file mode 100644
index 000..41691c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/spi-ls7a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson LS7A PCH SPI Controller
+
+all0f:
+ - $ref: "spi-controller.yaml#"
+
+maintainers:
+ - Qing Zhang
+
+description: |
+ This controller can be found in Loongson-3 systems with LS7A PCH.
+
+properties:
+ "#address-cells": true
+ "#size-cells": true
+
+ compatible:
+const: loongson,ls7a-spi
+
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - num-chipselects
+
+unevaluatedProperties: false
+
+examples:
+ - |
+spi@16,0 {
+compatible = "pci0014,7a0b.0",
+"pci0014,7a0b",
+"pciclass088000",
+"pciclass0800";
+
+reg = <0xb000 0x0 0x0 0x0 0x0>;
+#address-cells = <1>;
+#size-cells = <0>;
+num-chipselects = <0>;
+};
+
+...
--
2.1.0
[GIT PULL] Crypto Update for 5.11
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. - Enable crypto-engine retry mechanism in caam. - Enable support for crypto engine on sdm845 in qce. - Add HiSilicon PRNG driver support. Please note that there is a merge conflict in the MAINTAINERS file with the drm tree due to the Keem Bay driver. The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec: Linux 5.10-rc1 (2020-10-25 15:14:11 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 linus for you to fetch changes up to 93cebeb1c21a65b92636aaa278a32fbc0415ec67: crypto: qat - add capability detection logic in qat_4xxx (2020-12-11 21:54:16 +1100) Adam Guerin (2): crypto: qat - remove cast for mailbox CSR crypto: qat - replace pci with PCI in comments Ahsan Atta (1): crypto: qat - num_rings_per_bank is device dependent Ard Biesheuvel (14): crypto: arm64/poly1305-neon - reorder PAC authentication with SP update crypto: arm/chacha-neon - optimize for non-block size multiples crypto: arm64/chacha - simplify tail block handling crypto: arm64/gcm - move authentication tag check to SIMD domain crypto: aegis128 - wipe plaintext and tag if decryption fails crypto: aegis128/neon - optimize tail block handling crypto: aegis128/neon - move final tag check to SIMD domain crypto: aegis128 - expose SIMD code path as separate driver crypto: tcrypt - don't initialize at subsys_initcall time crypto: tcrypt - permit tcrypt.ko to be builtin crypto: tcrypt - include 1420 byte blocks in aead and skcipher benchmarks crypto: ecdh - avoid unaligned accesses in ecdh_set_secret() crypto: arm/aes-ce - work around Cortex-A57/A72 silion errata crypto: aegis128 - avoid spurious references crypto_aegis128_update_simd Arnd Bergmann (1): crypto: atmel-i2c - select CONFIG_BITREVERSE Arvind Sankar (6): crypto: lib/sha256 - Use memzero_explicit() for clearing state crypto: hash - Use memzero_explicit() for clearing state crypto: lib/sha256 - Don't clear temporary variables crypto: lib/sha256 - Clear W[] in sha256_update() instead of sha256_transform() crypto: lib/sha256 - Unroll SHA256 loop 8 times intead of 64 crypto: lib/sha256 - Unroll LOAD and BLEND loops Christophe JAILLET (3): crypto: cavium/zip - Use dma_set_mask_and_coherent to simplify code crypto: marvell/octeontx - Use dma_set_mask_and_coherent to simplify code crypto: cavium - Use dma_set_mask_and_coherent to simplify code Christophe Leroy (2): crypto: talitos - Endianess in current_desc_hdr() crypto: talitos - Fix return type of current_desc_hdr() Colin Ian King (2): crypto: inside-secure - Fix sizeof() mismatch crypto: kconfig - fix a couple of spelling mistakes Corentin Labbe (1): crypto: sun8i-ce - fix two error path's memory leak Daniele Alessandrelli (1): dt-bindings: Add Keem Bay OCS AES bindings Eric Biggers (8): crypto: x86/aes - remove unused file aes_glue.c crypto: aead - add crypto_aead_driver_name() crypto: testmgr - always print the actual hash driver name crypto: testmgr - always print the actual AEAD driver name crypto: testmgr - always print the actual skcipher driver name crypto: testmgr - WARN on test failure crypto: af_alg - avoid undefined behavior accessing salg_name crypto: sha - split sha.h into sha1.h and sha2.h Gilad Ben-Yossef (1): crypto: ccree - rework cache parameters handling Giovanni Cabiddu (33): crypto: qat - remove unused function crypto: qat - mask device capabilities with soft straps crypto: qat - fix configuration of iov threads crypto: qat - split transport CSR access logic crypto: qat - relocate GEN2 CSR access code crypto: qat - abstract admin interface crypto: qat - add packed to init admin structures crypto: qat - rename ME in AE crypto: qat - change admin sequence crypto: qat - use admin mask to send fw constants crypto: qat - update constants table crypto: qat - remove writes into WQCFG crypto: qat - remove unused macros in arbiter module crypto: qat - abstract arbiter access crypto: qat - register crypto instances based on capability crypto: qat - enable ring after pair is programmed crypto: qat - abstract build ring base crypto: qat - replace constant masks with GENMASK crypto: qat - use BIT_ULL() - 1 pattern for masks crypto: qat - abstract writes to arbiter enable crypto: qat - remove
[GIT PULL] fsverity updates for 5.11
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 bde493349025ca0559e2fff88592935af3b8df19: fs-verity: move structs needed for file signing to UAPI header (2020-11-23 19:30:14 -0800) Some cleanups for fs-verity: - Rename some names that have been causing confusion. - Move structs needed for file signing to the UAPI header. Eric Biggers (4): fs-verity: remove filenames from file comments fs-verity: rename fsverity_signed_digest to fsverity_formatted_digest fs-verity: rename "file measurement" to "file digest" fs-verity: move structs needed for file signing to UAPI header Documentation/filesystems/fsverity.rst | 68 -- fs/verity/enable.c | 8 ++-- fs/verity/fsverity_private.h | 36 ++ fs/verity/hash_algs.c | 2 +- fs/verity/init.c | 2 +- fs/verity/measure.c| 12 +++--- fs/verity/open.c | 24 ++-- fs/verity/signature.c | 14 +++ fs/verity/verify.c | 2 +- include/uapi/linux/fsverity.h | 49 10 files changed, 116 insertions(+), 101 deletions(-)
Re: [PATCH 2/8] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode
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 a dozen lines and a if (IS_ENABLED(... in core code. >>> Your change is common code, but a significant complexity (which >>> affects all archs) so needs a lot more review and testing at this >>> point. >> >> I don't think it's ready for this merge window. > > Yes next one I meant (aka this one for development perspective :)). > >> I read the early >> patches again, and I think they make the membarrier code worse, not >> better. > > Mathieu and I disagree, so we are at an impasse. Well actually not really, I went and cut out the exit_lazy_tlb stuff from the patch series, those are better to be untangled anyway. I think an earlier version had something in exit_lazy_tlb for the mm refcounting change but it's not required now anyway. I'll split them out and just work on the shoot lazies series for now, I might revisit exit_lazy_tlb after the dust settles from that and the current membarrier changes. I'll test and repost shortly. Thanks, Nick
Re: Linux 5.10
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. There's a fair amount of fixes in here, > > including a few last-minute reverts for things that didn't get fixed, > > but nothing makes me go "we need another week". > > ... > > > Mike Snitzer (1): > > md: change mddev 'chunk_sectors' from int to unsigned > > Seems to be broken. This breaks mounting my raid6 partition: > > [ 87.290698] attempt to access beyond end of device >md0: rw=4096, want=13996467328, limit=6261202944 > [ 87.293371] attempt to access beyond end of device >md0: rw=4096, want=13998564480, limit=6261202944 > [ 87.296045] BTRFS warning (device md0): couldn't read tree root > [ 87.300056] BTRFS error (device md0): open_ctree failed > > Reverting it goes back to the -rc7 behaviour where it mounts fine. If the developer/maintainer(s) agree, I can revert this and push out a 5.10.1, just let me know. thanks, greg k-h
[GIT PULL] fscrypt updates for 5.11
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 a14d0b6764917b21ee6fdfd2a8a4c2920fbefcce: fscrypt: allow deleting files with unsupported encryption policy (2020-12-02 18:25:01 -0800) This release there are some fixes for longstanding problems, as well as some cleanups: - Fix a race condition where a duplicate filename could be created in an encrypted directory if a syscall that creates a new filename raced with the directory's encryption key being added. - Allow deleting files that use an unsupported encryption policy. - Simplify the locking for 'struct fscrypt_master_key'. - Remove kernel-internal constants from the UAPI header. As usual, all these patches have been in linux-next with no reported issues, and I've tested them with xfstests. Eric Biggers (16): fscrypt: remove kernel-internal constants from UAPI header fscrypt: add fscrypt_is_nokey_name() ext4: prevent creating duplicate encrypted filenames f2fs: prevent creating duplicate encrypted filenames ubifs: prevent creating duplicate encrypted filenames fscrypt: remove unnecessary calls to fscrypt_require_key() fscrypt: simplify master key locking ext4: remove ext4_dir_open() f2fs: remove f2fs_dir_open() ubifs: remove ubifs_dir_open() ext4: don't call fscrypt_get_encryption_info() from dx_show_leaf() fscrypt: introduce fscrypt_prepare_readdir() fscrypt: move body of fscrypt_prepare_setattr() out-of-line fscrypt: move fscrypt_require_key() to fscrypt_private.h fscrypt: unexport fscrypt_get_encryption_info() fscrypt: allow deleting files with unsupported encryption policy fs/crypto/fname.c| 8 +++- fs/crypto/fscrypt_private.h | 56 +++--- fs/crypto/hooks.c| 55 +++-- fs/crypto/keyring.c | 10 +--- fs/crypto/keysetup.c | 44 +++-- fs/crypto/policy.c | 27 +++ fs/ext4/dir.c| 16 ++- fs/ext4/namei.c | 13 ++--- fs/f2fs/dir.c| 10 +--- fs/f2fs/f2fs.h | 2 + fs/ubifs/dir.c | 28 +-- include/linux/fscrypt.h | 112 --- include/uapi/linux/fscrypt.h | 5 +- 13 files changed, 227 insertions(+), 159 deletions(-)
Re: [PATCH v2 08/10] ovl: do not fail because of O_NOATIME
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 instead of failing.
> > >
> > > Signed-off-by: Miklos Szeredi
> > > ---
> > > fs/overlayfs/file.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c
> > > index dc767034d37b..d6ac7ac66410 100644
> > > --- a/fs/overlayfs/file.c
> > > +++ b/fs/overlayfs/file.c
> > > @@ -53,9 +53,10 @@ static struct file *ovl_open_realfile(const struct
> > > file *file,
> > > err = inode_permission(realinode, MAY_OPEN | acc_mode);
> > > if (err) {
> > > realfile = ERR_PTR(err);
> > > - } else if (!inode_owner_or_capable(realinode)) {
> > > - realfile = ERR_PTR(-EPERM);
> > > } else {
> > > + if (!inode_owner_or_capable(realinode))
> > > + flags &= ~O_NOATIME;
> > > +
> >
> > Isn't that going to break:
> >
> > flags |= OVL_OPEN_FLAGS;
> >
> > /* If some flag changed that cannot be changed then something's
> > amiss */
> > if (WARN_ON((file->f_flags ^ flags) & ~OVL_SETFL_MASK))
> >
> > IOW setting a flag that is allowed to change will fail because of
> > missing O_ATIME in file->f_flags.
>
> Well spotted. I just removed those lines as a fix. The check never
> triggered since its introduction in 4.19, so I guess it isn't worth
> adding more complexity for.
>
> >
> > I guess we need test coverage for SETFL.
>
> There might be some in ltp, haven't checked. Would be nice if the fs
> related ltp tests could be integrated into xfstests.
>
There is some test coverage for SETFL in xfstests.
The t_immutable tests for one, but those would not run if the mounter
has no CAP_LINUX_IMMUTABLE, so would not have been useful to
detect the problem above.
fsstress also seems to have support for SETFL ops, but I am not sure
in how many tests it is exercises and perhaps the relevant problem
would have been covered by some stress test that is not in the 'quick'
tests group.
Thanks,
Amir.
linux-next: build warning after merge of the tip tree
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 include/linux/wait_bit.h:8,
from include/linux/fs.h:6,
from include/linux/proc_fs.h:10,
from include/linux/efi.h:19,
from drivers/firmware/efi/libstub/arm32-stub.c:5:
drivers/firmware/efi/libstub/arm32-stub.c: In function 'handle_kernel_image':
include/linux/minmax.h:18:28: warning: comparison of distinct pointer types
lacks a cast
18 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
|^~
include/linux/minmax.h:32:4: note: in expansion of macro '__typecheck'
32 | (__typecheck(x, y) && __no_side_effects(x, y))
|^~~
include/linux/minmax.h:42:24: note: in expansion of macro '__safe_cmp'
42 | __builtin_choose_expr(__safe_cmp(x, y), \
|^~
include/linux/minmax.h:58:19: note: in expansion of macro '__careful_cmp'
58 | #define max(x, y) __careful_cmp(x, y, >)
| ^
arch/arm/include/asm/efi.h:74:25: note: in expansion of macro 'max'
74 | #define EFI_PHYS_ALIGN max(SZ_2M, roundup_pow_of_two(TEXT_OFFSET))
| ^~~
drivers/firmware/efi/libstub/arm32-stub.c:123:44: note: in expansion of macro
'EFI_PHYS_ALIGN'
123 | int alloc_size = MAX_UNCOMP_KERNEL_SIZE + EFI_PHYS_ALIGN;
|^~
include/linux/minmax.h:18:28: warning: comparison of distinct pointer types
lacks a cast
18 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
|^~
include/linux/minmax.h:32:4: note: in expansion of macro '__typecheck'
32 | (__typecheck(x, y) && __no_side_effects(x, y))
|^~~
include/linux/minmax.h:42:24: note: in expansion of macro '__safe_cmp'
42 | __builtin_choose_expr(__safe_cmp(x, y), \
|^~
include/linux/minmax.h:58:19: note: in expansion of macro '__careful_cmp'
58 | #define max(x, y) __careful_cmp(x, y, >)
| ^
arch/arm/include/asm/efi.h:74:25: note: in expansion of macro 'max'
74 | #define EFI_PHYS_ALIGN max(SZ_2M, roundup_pow_of_two(TEXT_OFFSET))
| ^~~
drivers/firmware/efi/libstub/arm32-stub.c:139:20: note: in expansion of macro
'EFI_PHYS_ALIGN'
139 | if ((alloc_base % EFI_PHYS_ALIGN) > slack) {
|^~
In file included from include/linux/list.h:9,
from include/linux/wait.h:7,
from include/linux/wait_bit.h:8,
from include/linux/fs.h:6,
from include/linux/proc_fs.h:10,
from include/linux/efi.h:19,
from drivers/firmware/efi/libstub/arm32-stub.c:5:
include/linux/minmax.h:18:28: warning: comparison of distinct pointer types
lacks a cast
18 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
|^~
include/linux/kernel.h:63:46: note: in definition of macro '__round_mask'
63 | #define __round_mask(x, y) ((__typeof__(x))((y)-1))
| ^
drivers/firmware/efi/libstub/arm32-stub.c:144:17: note: in expansion of macro
'round_up'
144 | kernel_base = round_up(alloc_base, EFI_PHYS_ALIGN);
| ^~~~
include/linux/minmax.h:32:4: note: in expansion of macro '__typecheck'
32 | (__typecheck(x, y) && __no_side_effects(x, y))
|^~~
include/linux/minmax.h:42:24: note: in expansion of macro '__safe_cmp'
42 | __builtin_choose_expr(__safe_cmp(x, y), \
|^~
include/linux/minmax.h:58:19: note: in expansion of macro '__careful_cmp'
58 | #define max(x, y) __careful_cmp(x, y, >)
| ^
arch/arm/include/asm/efi.h:74:25: note: in expansion of macro 'max'
74 | #define EFI_PHYS_ALIGN max(SZ_2M, roundup_pow_of_two(TEXT_OFFSET))
| ^~~
drivers/firmware/efi/libstub/arm32-stub.c:144:38: note: in expansion of macro
'EFI_PHYS_ALIGN'
144 | kernel_base = round_up(alloc_base, EFI_PHYS_ALIGN);
| ^~
include/linux/minmax.h:18:28: warning: comparison of distinct pointer types
lacks a cast
18 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
|^~
include/linux/kernel.h:63:46: note: in definition of macro '__round_mask'
63 | #define __round_mask(x, y) ((__typeof__(x))((y)-1))
| ^
drivers/firmware/efi/libstub/arm32-stub.c:148:17: note: in expansion of macro
'round_down'
148 | kernel_base = round_down(alloc_base,
Re: [PATCH] fuse: clean up redundant assignment
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 b/fs/fuse/dir.c index ff7dbeb16f88..f28eb54517ff 100644 --- a/fs/fuse/dir.c +++ b/fs/fuse/dir.c @@ -528,7 +528,6 @@ static int fuse_create_open(struct inode *dir, struct dentry *entry, if (!forget) goto out_err; - err = -ENOMEM; ff = fuse_file_alloc(fm); if (!ff) goto out_put_forget_req;
Re: [PATCH 1/3] PCI/ASPM: Use the path max in L1 ASPM latency check
[+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 Realtek NIC, etc and the I211 performance is poor with ASPM L1 enabled on both links in the path to it. The patch here disables ASPM on the upstream link and fixes the performance, but AFAICT the devices in that path give us no reason to disable L1. If I understand the spec correctly, the Realtek device should not be relevant to the I211 path.] On Sun, Dec 13, 2020 at 10:39:53PM +0100, Ian Kumlien wrote: > On Sun, Dec 13, 2020 at 12:47 AM Bjorn Helgaas wrote: > > On Sat, Oct 24, 2020 at 10:55:46PM +0200, Ian Kumlien wrote: > > > Make pcie_aspm_check_latency comply with the PCIe spec, specifically: > > > "5.4.1.2.2. Exit from the L1 State" > > > > > > Which makes it clear that each switch is required to initiate a > > > transition within 1μs from receiving it, accumulating this latency and > > > then we have to wait for the slowest link along the path before > > > entering L0 state from L1. > > > ... > > > > > On my specific system: > > > 03:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network > > > Connection (rev 03) > > > 04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device > > > 816e (rev 1a) > > > > > > Exit latency Acceptable latency > > > Tree: L1 L0s L1 L0s > > > -- --- - --- -- > > > 00:01.2 <32 us - > > > | 01:00.0 <32 us - > > > |- 02:03.0 <32 us - > > > | \03:00.0 <16 us <2us <64 us <512ns > > > | > > > \- 02:04.0 <32 us - > > > \04:00.0 <64 us unlimited <64 us <512ns > > > > > > 04:00.0's latency is the same as the maximum it allows so as we walk the > > > path > > > the first switchs startup latency will pass the acceptable latency limit > > > for the link, and as a side-effect it fixes my issues with 03:00.0. > > > > > > Without this patch, 03:00.0 misbehaves and only gives me ~40 mbit/s over > > > links with 6 or more hops. With this patch I'm back to a maximum of ~933 > > > mbit/s. > > > > There are two paths here that share a Link: > > > > 00:01.2 --- 01:00.0 -- 02:03.0 --- 03:00.0 I211 NIC > > 00:01.2 --- 01:00.0 -- 02:04.0 --- 04:00.x multifunction Realtek > > > > 1) The path to the I211 NIC includes four Ports and two Links (the > >connection between 01:00.0 and 02:03.0 is internal Switch routing, > >not a Link). > > >The Ports advertise L1 exit latencies of <32us, <32us, <32us, > ><16us. If both Links are in L1 and 03:00.0 initiates L1 exit at T, > >01:00.0 initiates L1 exit at T + 1. A TLP from 03:00.0 may see up > >to 1 + 32 = 33us of L1 exit latency. > > > >The NIC can tolerate up to 64us of L1 exit latency, so it is safe > >to enable L1 for both Links. > > > > 2) The path to the Realtek device is similar except that the Realtek > >L1 exit latency is <64us. If both Links are in L1 and 04:00.x > >initiates L1 exit at T, 01:00.0 again initiates L1 exit at T + 1, > >but a TLP from 04:00.x may see up to 1 + 64 = 65us of L1 exit > >latency. > > > >The Realtek device can only tolerate 64us of latency, so it is not > >safe to enable L1 for both Links. It should be safe to enable L1 > >on the shared link because the exit latency for that link would be > ><32us. > > 04:00.0: > DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us > LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s > unlimited, L1 <64us > > So maximum latency for the entire link has to be <64 us > For the device to leave L1 ASPM takes <64us > > So the device itself is the slowest entry along the link, which > means that nothing else along that path can have ASPM enabled Yes. That's what I said above: "it is not safe to enable L1 for both Links." Unless I'm missing something, we agree on that. I also said that it should be safe to enable L1 on the shared Link (from 00:01.2 to 01:00.0) because if the downstream Link is always in L0, the exit latency of the shared Link should be <32us, and 04:00.x can tolerate 64us. > > > The original code path did: > > > 04:00:0-02:04.0 max latency 64-> ok > > > 02:04.0-01:00.0 max latency 32 +1 -> ok > > > 01:00.0-00:01.2 max latency 32 +2 -> ok > > > > > > And thus didn't see any L1 ASPM latency issues. > > > > > > The new code does: > > > 04:00:0-02:04.0 max latency 64-> ok > > > 02:04.0-01:00.0 max latency 64 +1 -> latency exceeded > > > 01:00.0-00:01.2 max latency 64 +2 -> latency exceeded > > > > [Nit: I don't think we should add 1 for the 02:04.0 -- 01:00.0 piece > > because that's internal Switch routing, not a Link. But even without > > that extra microsecond, this path does exceed the acceptable latency > > since 1 + 64 =
Re: [PATCH v2 04/10] ovl: make ioctl() safe
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 and uses potentially different value.
> > >
> > > The "Check the capability before cred override" comment misleading: user
> > > can skip this check by presenting benign flags first and then overwriting
> > > them to non-benign flags.
> > >
> > > Just remove the cred override for now, hoping this doesn't cause a
> > > regression.
> > >
> > > The proper solution is to create a new setxflags i_op (patches are in the
> > > works).
> > >
> > > Xfstests don't show a regression.
> > >
> > > Reported-by: Dmitry Vyukov
> > > Signed-off-by: Miklos Szeredi
> >
> > Looks reasonable
> >
> > Reviewed-by: Amir Goldstein
> >
> > > ---
> > > fs/overlayfs/file.c | 75 ++---
> > > 1 file changed, 3 insertions(+), 72 deletions(-)
> > >
> > > diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c
> > > index efccb7c1f9bc..3cd1590f2030 100644
> > > --- a/fs/overlayfs/file.c
> > > +++ b/fs/overlayfs/file.c
> > > @@ -541,46 +541,26 @@ static long ovl_real_ioctl(struct file *file,
> > > unsigned int cmd,
> > >unsigned long arg)
> > > {
> > > struct fd real;
> > > - const struct cred *old_cred;
> > > long ret;
> > >
> > > ret = ovl_real_fdget(file, );
> > > if (ret)
> > > return ret;
> > >
> > > - old_cred = ovl_override_creds(file_inode(file)->i_sb);
> > > ret = security_file_ioctl(real.file, cmd, arg);
> > > if (!ret)
> > > ret = vfs_ioctl(real.file, cmd, arg);
> > > - revert_creds(old_cred);
> > >
> > > fdput(real);
> > >
> > > return ret;
> > > }
> > >
> >
> >
> > I wonder if we shouldn't leave a comment behind to explain
> > that no override is intentional.
>
> Comment added.
>
> > I also wonder if "Permission model" sections shouldn't be saying
> > something about ioctl() (current task checks only)? or we just treat
> > this is a breakage of the permission model that needs to be fixed?
>
> This is a breakage of the permission model. But I don't think this is
> a serious breakage, or one that actually matters.
>
Perhaps, but there is a much bigger issue with this change IMO.
Not because of dropping rule (b) of the permission model, but because
of relaxing rule (a).
Should overlayfs respect the conservative interpretation as it partly did
until this commit, a lower file must not lose IMMUTABLE/APPEND_ONLY
after copy up, but that is exactly what is going to happen if we first
copy up and then fail permission check on setting the flags.
It's true that before this change, file could still be copied up and system
crash would leave it without the flags, but after the change it is much
worse as the flags completely lose their meaning on lower files when
any unprivileged process can remove them.
So I suggest that you undo all the changes except for the no override.
And this calls for a fork of generic/545 to overlay test with lower files.
Thanks,
Amir.
Re: Linux 5.10
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 reverts for things that didn't get fixed, > but nothing makes me go "we need another week". ... > Mike Snitzer (1): > md: change mddev 'chunk_sectors' from int to unsigned Seems to be broken. This breaks mounting my raid6 partition: [ 87.290698] attempt to access beyond end of device md0: rw=4096, want=13996467328, limit=6261202944 [ 87.293371] attempt to access beyond end of device md0: rw=4096, want=13998564480, limit=6261202944 [ 87.296045] BTRFS warning (device md0): couldn't read tree root [ 87.300056] BTRFS error (device md0): open_ctree failed Reverting it goes back to the -rc7 behaviour where it mounts fine. Dave
[PATCH v2] leds: Use DEVICE_ATTR_{RW, RO, WO} macros
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 commit message
drivers/leds/leds-blinkm.c| 24
drivers/leds/leds-lm3530.c| 10 +-
drivers/leds/leds-lm355x.c| 8
drivers/leds/leds-lm3642.c| 16
drivers/leds/leds-max8997.c | 12 ++--
drivers/leds/leds-netxbig.c | 12 ++--
drivers/leds/leds-ss4200.c| 12 ++--
drivers/leds/leds-wm831x-status.c | 12 ++--
8 files changed, 53 insertions(+), 53 deletions(-)
diff --git a/drivers/leds/leds-blinkm.c b/drivers/leds/leds-blinkm.c
index e11fe1788242..b4e1fdff4186 100644
--- a/drivers/leds/leds-blinkm.c
+++ b/drivers/leds/leds-blinkm.c
@@ -192,13 +192,13 @@ static int store_color_common(struct device *dev, const
char *buf, int color)
return 0;
}
-static ssize_t show_red(struct device *dev, struct device_attribute *attr,
+static ssize_t red_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
return show_color_common(dev, buf, RED);
}
-static ssize_t store_red(struct device *dev, struct device_attribute *attr,
+static ssize_t red_store(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
int ret;
@@ -209,15 +209,15 @@ static ssize_t store_red(struct device *dev, struct
device_attribute *attr,
return count;
}
-static DEVICE_ATTR(red, S_IRUGO | S_IWUSR, show_red, store_red);
+static DEVICE_ATTR_RW(red);
-static ssize_t show_green(struct device *dev, struct device_attribute *attr,
+static ssize_t green_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
return show_color_common(dev, buf, GREEN);
}
-static ssize_t store_green(struct device *dev, struct device_attribute *attr,
+static ssize_t green_store(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
@@ -229,15 +229,15 @@ static ssize_t store_green(struct device *dev, struct
device_attribute *attr,
return count;
}
-static DEVICE_ATTR(green, S_IRUGO | S_IWUSR, show_green, store_green);
+static DEVICE_ATTR_RW(green);
-static ssize_t show_blue(struct device *dev, struct device_attribute *attr,
+static ssize_t blue_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
return show_color_common(dev, buf, BLUE);
}
-static ssize_t store_blue(struct device *dev, struct device_attribute *attr,
+static ssize_t blue_store(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
int ret;
@@ -248,16 +248,16 @@ static ssize_t store_blue(struct device *dev, struct
device_attribute *attr,
return count;
}
-static DEVICE_ATTR(blue, S_IRUGO | S_IWUSR, show_blue, store_blue);
+static DEVICE_ATTR_RW(blue);
-static ssize_t show_test(struct device *dev, struct device_attribute *attr,
+static ssize_t test_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
return scnprintf(buf, PAGE_SIZE,
"#Write into test to start test sequence!#\n");
}
-static ssize_t store_test(struct device *dev, struct device_attribute *attr,
+static ssize_t test_store(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
@@ -273,7 +273,7 @@ static ssize_t store_test(struct device *dev, struct
device_attribute *attr,
return count;
}
-static DEVICE_ATTR(test, S_IRUGO | S_IWUSR, show_test, store_test);
+static DEVICE_ATTR_RW(test);
/* TODO: HSB, fade, timeadj, script ... */
diff --git a/drivers/leds/leds-lm3530.c b/drivers/leds/leds-lm3530.c
index 2f8362f6bf75..2db455efd4b1 100644
--- a/drivers/leds/leds-lm3530.c
+++ b/drivers/leds/leds-lm3530.c
@@ -346,8 +346,8 @@ static void lm3530_brightness_set(struct led_classdev
*led_cdev,
}
}
-static ssize_t lm3530_mode_get(struct device *dev,
- struct device_attribute *attr, char *buf)
+static ssize_t mode_show(struct device *dev,
+struct device_attribute *attr, char *buf)
{
struct led_classdev *led_cdev = dev_get_drvdata(dev);
struct lm3530_data *drvdata;
@@ -365,8 +365,8 @@ static ssize_t lm3530_mode_get(struct device *dev,
return len;
}
-static ssize_t lm3530_mode_set(struct device *dev, struct device_attribute
- *attr, const char *buf, size_t size)
+static ssize_t mode_store(struct device *dev, struct device_attribute
+ *attr, const char *buf, size_t size)
{
Re: Linux 5.10
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. There's a fair amount of fixes in here, > > including a few last-minute reverts for things that didn't get fixed, > > but nothing makes me go "we need another week". > > ... > > > Mike Snitzer (1): > > md: change mddev 'chunk_sectors' from int to unsigned > > Seems to be broken. This breaks mounting my raid6 partition: > > [ 87.290698] attempt to access beyond end of device >md0: rw=4096, want=13996467328, limit=6261202944 > [ 87.293371] attempt to access beyond end of device >md0: rw=4096, want=13998564480, limit=6261202944 > [ 87.296045] BTRFS warning (device md0): couldn't read tree root > [ 87.300056] BTRFS error (device md0): open_ctree failed > > Reverting it goes back to the -rc7 behaviour where it mounts fine. Another data point from the md setup in dmesg.. good: [4.614957] md/raid:md0: device sdd1 operational as raid disk 3 [4.614960] md/raid:md0: device sda1 operational as raid disk 0 [4.614962] md/raid:md0: device sdc1 operational as raid disk 2 [4.614963] md/raid:md0: device sdf1 operational as raid disk 4 [4.614964] md/raid:md0: device sdg1 operational as raid disk 1 [4.615156] md/raid:md0: raid level 5 active with 5 out of 5 devices, algorithm 2 [4.645563] md0: detected capacity change from 0 to 12001828929536 bad: [5.315036] md/raid:md0: device sda1 operational as raid disk 0 [5.316220] md/raid:md0: device sdd1 operational as raid disk 3 [5.317389] md/raid:md0: device sdc1 operational as raid disk 2 [5.318613] md/raid:md0: device sdf1 operational as raid disk 4 [5.319748] md/raid:md0: device sdg1 operational as raid disk 1 [5.321155] md/raid:md0: raid level 5 active with 5 out of 5 devices, algorithm 2 [5.370257] md0: detected capacity change from 0 to 3205735907328
linux-next: build failure after merge of the watchdog tree
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 'iTCO_wdt_start':
drivers/watchdog/iTCO_wdt.c:280:17: error: 'struct watchdog_device' has no
member named 'dev'
280 | dev_err(wd_dev->dev, "failed to reset NO_REBOOT flag, reboot disabled
by hardware/BIOS\n");
| ^~
include/linux/dev_printk.h:112:11: note: in definition of macro 'dev_err'
112 | _dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~
Caused by commit
9c612b338fdf ("watchdog: iTCO_wdt: use dev_*() instead of pr_*() for logging")
I have used the wtchdog tree from next-20201211 for today.
--
Cheers,
Stephen Rothwell
pgps1PooKlPUM.pgp
Description: OpenPGP digital signature
[PATCH v3] usb: xhci-mtk: fix unreleased bandwidth data
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 still remain at the table.
This patch adds two more hooks from check_bandwidth() and
reset_bandwidth(), and make mtk-xhci to releases all failed endpoints
from reset_bandwidth().
Fixes: 4b0f7a77fb3c ("usb: xhci-mtk: supports bandwidth scheduling with
multi-TT")
Signed-off-by: Ikjoon Jang
---
Changes in v3:
- drop unrelated code cleanups in v2
- change Fixes tag to keep dependency
Changes in v2:
- fix a 0-day warning from unused variable
- split one big patch into three patches
- fix wrong offset in mediatek hw flags
drivers/usb/host/xhci-mtk-sch.c | 121 ++--
drivers/usb/host/xhci-mtk.h | 13
drivers/usb/host/xhci.c | 9 +++
3 files changed, 106 insertions(+), 37 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-sch.c
index 45c54d56ecbd..72c493758c3f 100644
--- a/drivers/usb/host/xhci-mtk-sch.c
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -200,6 +200,7 @@ static struct mu3h_sch_ep_info *create_sch_ep(struct
usb_device *udev,
sch_ep->sch_tt = tt;
sch_ep->ep = ep;
+ INIT_LIST_HEAD(_ep->tt_endpoint);
return sch_ep;
}
@@ -583,6 +584,8 @@ int xhci_mtk_sch_init(struct xhci_hcd_mtk *mtk)
mtk->sch_array = sch_array;
+ INIT_LIST_HEAD(>bw_ep_list_new);
+
return 0;
}
EXPORT_SYMBOL_GPL(xhci_mtk_sch_init);
@@ -601,19 +604,14 @@ int xhci_mtk_add_ep_quirk(struct usb_hcd *hcd, struct
usb_device *udev,
struct xhci_ep_ctx *ep_ctx;
struct xhci_slot_ctx *slot_ctx;
struct xhci_virt_device *virt_dev;
- struct mu3h_sch_bw_info *sch_bw;
struct mu3h_sch_ep_info *sch_ep;
- struct mu3h_sch_bw_info *sch_array;
unsigned int ep_index;
- int bw_index;
- int ret = 0;
xhci = hcd_to_xhci(hcd);
virt_dev = xhci->devs[udev->slot_id];
ep_index = xhci_get_endpoint_index(>desc);
slot_ctx = xhci_get_slot_ctx(xhci, virt_dev->in_ctx);
ep_ctx = xhci_get_ep_ctx(xhci, virt_dev->in_ctx, ep_index);
- sch_array = mtk->sch_array;
xhci_dbg(xhci, "%s() type:%d, speed:%d, mpkt:%d, dir:%d, ep:%p\n",
__func__, usb_endpoint_type(>desc), udev->speed,
@@ -632,39 +630,34 @@ int xhci_mtk_add_ep_quirk(struct usb_hcd *hcd, struct
usb_device *udev,
return 0;
}
- bw_index = get_bw_index(xhci, udev, ep);
- sch_bw = _array[bw_index];
-
sch_ep = create_sch_ep(udev, ep, ep_ctx);
if (IS_ERR_OR_NULL(sch_ep))
return -ENOMEM;
setup_sch_info(udev, ep_ctx, sch_ep);
- ret = check_sch_bw(udev, sch_bw, sch_ep);
- if (ret) {
- xhci_err(xhci, "Not enough bandwidth!\n");
- if (is_fs_or_ls(udev->speed))
- drop_tt(udev);
-
- kfree(sch_ep);
- return -ENOSPC;
- }
+ list_add_tail(_ep->endpoint, >bw_ep_list_new);
- list_add_tail(_ep->endpoint, _bw->bw_ep_list);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(xhci_mtk_add_ep_quirk);
- ep_ctx->reserved[0] |= cpu_to_le32(EP_BPKTS(sch_ep->pkts)
- | EP_BCSCOUNT(sch_ep->cs_count) | EP_BBM(sch_ep->burst_mode));
- ep_ctx->reserved[1] |= cpu_to_le32(EP_BOFFSET(sch_ep->offset)
- | EP_BREPEAT(sch_ep->repeat));
+static void xhci_mtk_drop_ep(struct xhci_hcd_mtk *mtk, struct usb_device *udev,
+struct mu3h_sch_ep_info *sch_ep)
+{
+ struct xhci_hcd *xhci = hcd_to_xhci(mtk->hcd);
+ int bw_index = get_bw_index(xhci, udev, sch_ep->ep);
+ struct mu3h_sch_bw_info *sch_bw = >sch_array[bw_index];
- xhci_dbg(xhci, " PKTS:%x, CSCOUNT:%x, BM:%x, OFFSET:%x, REPEAT:%x\n",
- sch_ep->pkts, sch_ep->cs_count, sch_ep->burst_mode,
- sch_ep->offset, sch_ep->repeat);
+ update_bus_bw(sch_bw, sch_ep, 0);
+ list_del(_ep->endpoint);
- return 0;
+ if (sch_ep->sch_tt) {
+ list_del(_ep->tt_endpoint);
+ drop_tt(udev);
+ }
+ kfree(sch_ep);
}
-EXPORT_SYMBOL_GPL(xhci_mtk_add_ep_quirk);
void xhci_mtk_drop_ep_quirk(struct usb_hcd *hcd, struct usb_device *udev,
struct usb_host_endpoint *ep)
@@ -675,7 +668,7 @@ void xhci_mtk_drop_ep_quirk(struct usb_hcd *hcd, struct
usb_device *udev,
struct xhci_virt_device *virt_dev;
struct mu3h_sch_bw_info *sch_array;
struct mu3h_sch_bw_info *sch_bw;
- struct mu3h_sch_ep_info *sch_ep;
+ struct mu3h_sch_ep_info *sch_ep, *tmp;
int bw_index;
xhci = hcd_to_xhci(hcd);
@@ -694,17 +687,71 @@ void
RE: [PATCH v2 07/10] gpio: bd9571mwv: Add BD9574MWF support
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 doesn't
> > support it for now.
>
> nit:
> Perhaps mention which feature?
BD9574MWF GPIO[01] have 4 functions like below.
1) GPIO, 2) "RECOV_GPOUT", 3) "FREQSEL", 4) "RTC_IN"
It seems "pinctrl" features though and I don't know
these features in detail for now.
> And I think you mean the driver does not support it yet?
You're correct. Now this driver only support the 1) GPIO.
> >
> > Signed-off-by: Yoshihiro Shimoda
>
> FWIW:
> Reviewed-By: Matti Vaittinen
Thank you for your review!
> > ---
> > drivers/gpio/gpio-bd9571mwv.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpio/gpio-bd9571mwv.c b/drivers/gpio/gpio-
> > bd9571mwv.c
> > index 0e5395f..df6102b 100644
> > --- a/drivers/gpio/gpio-bd9571mwv.c
> > +++ b/drivers/gpio/gpio-bd9571mwv.c
> > @@ -1,6 +1,6 @@
> > // SPDX-License-Identifier: GPL-2.0-only
> > /*
> > - * ROHM BD9571MWV-M GPIO driver
> > + * ROHM BD9571MWV-M and BD9574MWF-M GPIO driver
> > *
> > * Copyright (C) 2017 Marek Vasut
> > *
> > @@ -10,6 +10,7 @@
> > */
> >
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -118,7 +119,8 @@ static int bd9571mwv_gpio_probe(struct
> > platform_device *pdev)
> > }
> >
> > static const struct platform_device_id bd9571mwv_gpio_id_table[] = {
> > - { "bd9571mwv-gpio", },
> > + { "bd9571mwv-gpio", ROHM_CHIP_TYPE_BD9571 },
> > + { "bd9574mwf-gpio", ROHM_CHIP_TYPE_BD9574 },
>
> I guess these CHIP_TYPES are used by subsequent patches?
>
> I guess this means the existing functionality in both chips is same,
> right? (GPIO register addresses etc? - I don't have BD9571 data-sheet
> so I can't check)
Yes, the existing functionality in both chips is same.
GPIO register addresses and bits are the same.
Note that BD9574MWF has one more register, but the driver
doesn't use it for now.
Best regards,
Yoshihiro Shimoda
Bug in recent kernel timer implementation
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'. Linux x86, Linux x64. HZ=250. init_timer(_timer); my_timer.function = testjiffy_timer_function; my_timer.expires = jiffies + 1; add_timer(_timer); So, according to comments in add_timer, testjiffy_timer_function should be called next timer tick, 4ms later. If you will run this code in Linux 3.16.0 - it will call testjiffy_timer_function in the next timer tick (4ms later), as expected. If you will run this code in Linux 4.9.0 - it will call testjiffy_timer_function in the on second timer tick (8ms later)... If you will modify code for Linux > 4.15 (setup_timer/mod_timer) - you will get the same strange behaviour... You can get code from here https://stackoverflow.com/questions/16920238/reliability-of-linux-kernel-add-timer-at-resolution-of-one-jiffy 3.16.0 [52728.313029] Init testjiffy: 0 ; HZ: 250 ; 1/HZ (ms): 4 [52728.313720] testjiffy_timer_function: runcount 1, jif=13110976, oldjif=13110975, delta=1 [52728.318743] testjiffy_timer_function: runcount 2, jif=13110977, oldjif=13110976, delta=1 [52728.323304] testjiffy_timer_function: runcount 3, jif=13110978, oldjif=13110977, delta=1 [52728.325824] testjiffy_timer_function: runcount 4, jif=13110979, oldjif=13110978, delta=1 [52728.330811] testjiffy_timer_function: runcount 5, jif=13110980, oldjif=13110979, delta=1 [52728.335802] testjiffy_timer_function: runcount 6, jif=13110981, oldjif=13110980, delta=1 [52728.338305] testjiffy_timer_function: runcount 7, jif=13110982, oldjif=13110981, delta=1 [52728.343298] testjiffy_timer_function: runcount 8, jif=13110983, oldjif=13110982, delta=1 [52728.345806] testjiffy_timer_function: runcount 9, jif=13110984, oldjif=13110983, delta=1 [52728.350885] testjiffy_timer_function: runcount 10, jif=13110985, oldjif=13110984, delta=1 [52729.317263] Exit testjiffy 4.9.0 [52073.085341] Init testjiffy: 0 ; HZ: 250 ; 1/HZ (ms): 4 [52073.092322] testjiffy_timer_function: runcount 1, jif=4307910976, oldjif=4307910974, delta=2 [52073.099818] testjiffy_timer_function: runcount 2, jif=4307910978, oldjif=4307910976, delta=2 [52073.109830] testjiffy_timer_function: runcount 3, jif=4307910980, oldjif=4307910978, delta=2 [52073.117362] testjiffy_timer_function: runcount 4, jif=4307910982, oldjif=4307910980, delta=2 [52073.124845] testjiffy_timer_function: runcount 5, jif=4307910984, oldjif=4307910982, delta=2 [52073.132315] testjiffy_timer_function: runcount 6, jif=4307910986, oldjif=4307910984, delta=2 [52073.139816] testjiffy_timer_function: runcount 7, jif=4307910988, oldjif=4307910986, delta=2 [52073.149824] testjiffy_timer_function: runcount 8, jif=4307910990, oldjif=4307910988, delta=2 [52073.157303] testjiffy_timer_function: runcount 9, jif=4307910992, oldjif=4307910990, delta=2 [52073.164824] testjiffy_timer_function: runcount 10, jif=4307910994, oldjif=4307910992, delta=2 [52074.089574] Exit testjiffy
[PATCH v2] i2c: sprd: use a specific timeout to avoid system hang up issue
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 up. To avoid that
happen, this patch adds a specific timeout for message transfer.
Fixes: 8b9ec0719834 ("i2c: Add Spreadtrum I2C controller driver")
Signed-off-by: Linhua Xu
Signed-off-by: Chunyan Zhang
---
* Changes since v1:
- Addressed Wolfram's comments for code;
- Changed to use Signed-off-by instead of Original-by;
- Fixed a compile error.
---
drivers/i2c/busses/i2c-sprd.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-sprd.c b/drivers/i2c/busses/i2c-sprd.c
index 19cda6742423..b9f58a4b2281 100644
--- a/drivers/i2c/busses/i2c-sprd.c
+++ b/drivers/i2c/busses/i2c-sprd.c
@@ -72,6 +72,8 @@
/* timeout (ms) for pm runtime autosuspend */
#define SPRD_I2C_PM_TIMEOUT1000
+/* timeout (ms) for transfer message */
+#define I2C_XFER_TIMEOUT 1000
/* SPRD i2c data structure */
struct sprd_i2c {
@@ -244,6 +246,7 @@ static int sprd_i2c_handle_msg(struct i2c_adapter *i2c_adap,
struct i2c_msg *msg, bool is_last_msg)
{
struct sprd_i2c *i2c_dev = i2c_adap->algo_data;
+ unsigned long time_left;
i2c_dev->msg = msg;
i2c_dev->buf = msg->buf;
@@ -273,7 +276,10 @@ static int sprd_i2c_handle_msg(struct i2c_adapter
*i2c_adap,
sprd_i2c_opt_start(i2c_dev);
- wait_for_completion(_dev->complete);
+ time_left = wait_for_completion_timeout(_dev->complete,
+ msecs_to_jiffies(I2C_XFER_TIMEOUT));
+ if (!time_left)
+ return -EIO;
return i2c_dev->err;
}
--
2.25.1
RE: [PATCH v2 04/10] regulator: bd9571mwv: Add BD9574MWF support
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 VID.
>
> I'd like to understand what is VID?
It seems reading some voltages from registers.
For example, BD9571 has "VD18_VID" register which
is prohibit to write. But, BD9574 doesn't have this
register. Also, the driver names "vid_ops",
so I described "VID" here. Perhaps, we should revise
the description to clear. (Please look "Updated description" in this email.)
> >
> > Signed-off-by: Yoshihiro Shimoda
> > ---
> > drivers/regulator/bd9571mwv-regulator.c | 10 --
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/regulator/bd9571mwv-regulator.c
> > b/drivers/regulator/bd9571mwv-regulator.c
> > index 02120b0..041339b 100644
> > --- a/drivers/regulator/bd9571mwv-regulator.c
> > +++ b/drivers/regulator/bd9571mwv-regulator.c
> > @@ -1,6 +1,6 @@
> > // SPDX-License-Identifier: GPL-2.0
> > /*
> > - * ROHM BD9571MWV-M regulator driver
> > + * ROHM BD9571MWV-M and BD9574MWF-M regulator driver
> > *
> > * Copyright (C) 2017 Marek Vasut
> > *
> > @@ -9,6 +9,7 @@
> > * NOTE: VD09 is missing
> > */
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -277,6 +278,7 @@ static int bd9571mwv_regulator_probe(struct
> > platform_device *pdev)
> > struct regulator_dev *rdev;
> > unsigned int val;
> > int i;
> > + enum rohm_chip_type chip = platform_get_device_id(pdev)-
> > >driver_data;
> >
> > bdreg = devm_kzalloc(>dev, sizeof(*bdreg), GFP_KERNEL);
> > if (!bdreg)
> > @@ -292,6 +294,9 @@ static int bd9571mwv_regulator_probe(struct
> > platform_device *pdev)
> > config.regmap = bdreg->regmap;
> >
> > for (i = 0; i < ARRAY_SIZE(regulators); i++) {
> > + /* BD9574MWF supports DVFS only */
> > + if (chip == ROHM_CHIP_TYPE_BD9574 && regulators[i].id
> > != DVFS)
> > + continue;
>
> Does this mean that reading VD09 voltage is not supported by driver?
Yes. Also, reading VD{18,25,33} voltage are not supported.
> (I
> assumed VD09 initial voltage can be set from eeprom(?) and read by
> driver - I may be wrong though). Perhaps it is worth mentioning in the
> commit message as a driver restriction?
Yes, these voltage can be set from eeprom and read by driver.
So, I updated the description like below.
-- Updated description --
Add support for BD9574MWF which is similar chip with BD9571MWV.
Note that since BD9574MWF doesn't have avs_ops and vid_ops
related registers, this driver avoids to use these registers
if BD9574MWF is used.
> And just asking out of the curiosity - are the other voltage rails
> listed in data-sheet (VD18, DDR0, VD33, VD09 and LDO1,...,LDO4) set-up
> from DT as fixed-regulators? Any reason why they are not set-up here?
TBH, I don't know why. Perhaps, the driver cannot read DDR0, LDO[1-4] values?
Best regards,
Yoshihiro Shimoda
Re: [PATCH v2 14/21] phy: sun4i-usb: Rework "pmu_unk1" handling
在 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 register is PHYCTL register for
> > each
> > individual PHY, and the bit that is cleared is
> > called SUNXI_HCI_PHY_CTRL_SIDDQ in the BSP (similar to
> > the USBC_PHY_CTL_SIDDQ we cleared for main PHYCTL).
In addition, both the BIT(1) in old PHYs and the BIT(3) in new PHYs are
SIDDQ. (In BSP it's a #define inside #if)
Should we add some flag for 28nm PHY?
>
> Oh, right, somehow I failed to find this in the BSP, I guess I got
> confused over that similar symbol. I will put proper names to it.
In addition, the region at 0x800 is not PMU at all, but some [OE]HCI-
related control registers. The name "PMU" can only cover the first
register here.
We may need to address this.
>
> Thanks!
> Andre
>
> > > Generalise the existing code by allowing configs to specify a
> > > bitmask
> > > of bits to clear.
> > >
> > > Signed-off-by: Andre Przywara
> > > ---
> > > drivers/phy/allwinner/phy-sun4i-usb.c | 28 +++
> > >
> > >
> > > 1 file changed, 11 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c
> > > b/drivers/phy/allwinner/phy-sun4i-usb.c
> > > index 651d5e2a25ce..4ba0699e0bb4 100644
> > > --- a/drivers/phy/allwinner/phy-sun4i-usb.c
> > > +++ b/drivers/phy/allwinner/phy-sun4i-usb.c
> > > @@ -115,9 +115,9 @@ struct sun4i_usb_phy_cfg {
> > > int hsic_index;
> > > enum sun4i_usb_phy_type type;
> > > u32 disc_thresh;
> > > + u32 pmu_unk1_clrbits;
> > > u8 phyctl_offset;
> > > bool dedicated_clocks;
> > > - bool enable_pmu_unk1;
> > > bool phy0_dual_route;
> > > int missing_phys;
> > > };
> > > @@ -288,6 +288,12 @@ static int sun4i_usb_phy_init(struct phy
> > > *_phy)
> > > return ret;
> > > }
> > >
> > > + if (phy->pmu && data->cfg->pmu_unk1_clrbits) {
> > > + val = readl(phy->pmu + REG_PMU_UNK1);
> > > + val &= ~data->cfg->pmu_unk1_clrbits;
> > > + writel(val, phy->pmu + REG_PMU_UNK1);
> > > + }
> > > +
> > > if (data->cfg->type == sun8i_a83t_phy ||
> > > data->cfg->type == sun50i_h6_phy) {
> > > if (phy->index == 0) {
> > > @@ -297,11 +303,6 @@ static int sun4i_usb_phy_init(struct phy
> > > *_phy)
> > > writel(val, data->base + data->cfg-
> > > > phyctl_offset);
> > > }
> > > } else {
> > > - if (phy->pmu && data->cfg->enable_pmu_unk1) {
> > > - val = readl(phy->pmu + REG_PMU_UNK1);
> > > - writel(val & ~2, phy->pmu + REG_PMU_UNK1);
> > > - }
> > > -
> > > /* Enable USB 45 Ohm resistor calibration */
> > > if (phy->index == 0)
> > > sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN,
> > > 0x01, 1);
> > > @@ -867,7 +868,6 @@ static const struct sun4i_usb_phy_cfg
> > > sun4i_a10_cfg = {
> > > .disc_thresh = 3,
> > > .phyctl_offset = REG_PHYCTL_A10,
> > > .dedicated_clocks = false,
> > > - .enable_pmu_unk1 = false,
> > > };
> > >
> > > static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
> > > @@ -876,7 +876,6 @@ static const struct sun4i_usb_phy_cfg
> > > sun5i_a13_cfg = {
> > > .disc_thresh = 2,
> > > .phyctl_offset = REG_PHYCTL_A10,
> > > .dedicated_clocks = false,
> > > - .enable_pmu_unk1 = false,
> > > };
> > >
> > > static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
> > > @@ -885,7 +884,6 @@ static const struct sun4i_usb_phy_cfg
> > > sun6i_a31_cfg = {
> > > .disc_thresh = 3,
> > > .phyctl_offset = REG_PHYCTL_A10,
> > > .dedicated_clocks = true,
> > > - .enable_pmu_unk1 = false,
> > > };
> > >
> > > static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
> > > @@ -894,7 +892,6 @@ static const struct sun4i_usb_phy_cfg
> > > sun7i_a20_cfg = {
> > > .disc_thresh = 2,
> > > .phyctl_offset = REG_PHYCTL_A10,
> > > .dedicated_clocks = false,
> > > - .enable_pmu_unk1 = false,
> > > };
> > >
> > > static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
> > > @@ -903,7 +900,6 @@ static const struct sun4i_usb_phy_cfg
> > > sun8i_a23_cfg = {
> > > .disc_thresh = 3,
> > > .phyctl_offset = REG_PHYCTL_A10,
> > > .dedicated_clocks = true,
> > > - .enable_pmu_unk1 = false,
> > > };
> > >
> > > static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
> > > @@ -912,7 +908,6 @@ static const struct sun4i_usb_phy_cfg
> > > sun8i_a33_cfg = {
> > > .disc_thresh = 3,
> > > .phyctl_offset = REG_PHYCTL_A33,
> > > .dedicated_clocks = true,
> > > - .enable_pmu_unk1 = false,
> > > };
> > >
> > > static const struct sun4i_usb_phy_cfg sun8i_a83t_cfg = {
> > > @@ -929,7 +924,7 @@ static const struct sun4i_usb_phy_cfg
> > > sun8i_h3_cfg = {
> > > .disc_thresh = 3,
> > > .phyctl_offset = REG_PHYCTL_A33,
> > > .dedicated_clocks =
Re: [PATCH v2 5/5] clk: qcom: gcc: Add clock driver for SM8350
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,
> > > > > + .halt_check = BRANCH_HALT_DELAY,
> > > > > + .hwcg_reg = 0x26004,
> > > > > + .hwcg_bit = 1,
> > > > > + .clkr = {
> > > > > + .enable_reg = 0x26004,
> > > > > + .enable_mask = BIT(0),
> > > > > + .hw.init = &(struct clk_init_data){
> > > > > + .name = "gcc_camera_ahb_clk",
> > > > > + .flags = CLK_IS_CRITICAL,
> > > >
> > > > Why is it critical? Can we just enable it in driver probe and stop
> > > > modeling it as a clk?
> > >
> > > it does not have a parent we control, yeah it would make sense to do
> > > that. Tanya do you folks agree ..?
> > >
> >
> > Maybe it is needed for camera clk controller? Have to check other SoCs
> > and see if they're using it.
> >
>
> Yes, they would have to be left enabled.
>
> Vinod, could you please move them to probe, similar to kona/sc7180 where all
> the CRITICALs clocks are left enabled?
Thanks for the pointer, will do
Thanks
--
~Vinod
Re: WARNING in yurex_write/usb_submit_urb
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: https://syzkaller.appspot.com/x/.config?x=3416bb960d5c705d dashboard link: https://syzkaller.appspot.com/bug?extid=e87ebe0f7913f71f2ea5 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1583cf1750 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1182541350 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+e87ebe0f7913f71f2...@syzkaller.appspotmail.com [ cut here ] URB 91a49304 submitted while active WARNING: CPU: 0 PID: 8533 at drivers/usb/core/urb.c:378 usb_submit_urb+0x1228/0x14e0 drivers/usb/core/urb.c:378 Modules linked in: CPU: 0 PID: 8533 Comm: syz-executor014 Not tainted 5.10.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:usb_submit_urb+0x1228/0x14e0 drivers/usb/core/urb.c:378 Code: 89 de e8 eb c8 3b fc 84 db 0f 85 da f4 ff ff e8 ce d0 3b fc 4c 89 fe 48 c7 c7 40 58 e1 89 c6 05 62 6d a4 07 01 e8 74 4f 78 03 <0f> 0b e9 b8 f4 ff ff c7 44 24 14 01 00 00 00 e9 6f f5 ff ff 41 bd RSP: 0018:c9000187fcb8 EFLAGS: 00010282 RAX: RBX: RCX: RDX: 888015e73480 RSI: 8158c835 RDI: f5200030ff89 RBP: 19200030ffa9 R08: 0001 R09: 8880b9e30627 R10: R11: R12: 888017a40c00 R13: fff0 R14: 888017a40ce8 R15: 888011521a00 FS: 025f8880() GS:8880b9e0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fe0726b3000 CR3: 1c29c000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: yurex_write+0x3f4/0x840 drivers/usb/misc/yurex.c:493 vfs_write+0x28e/0xa30 fs/read_write.c:603 ksys_write+0x12d/0x250 fs/read_write.c:658 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x445809 Code: e8 8c e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 6b cc fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffe3d547598 EFLAGS: 0246 ORIG_RAX: 0001 RAX: ffda RBX: RCX: 00445809 RDX: 0001 RSI: 2740 RDI: 0004 RBP: edca R08: 000f R09: 004002e0 R10: R11: 0246 R12: 00402900 R13: 00402990 R14: R15:
Re: [PATCH v4 1/2] dt-bindings: pci: Retrain Link to work around Gen2 training defect.
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 >> ; linux-kernel@vger.kernel.org; Kishon Vijay >> Abraham I ; devicet...@vger.kernel.org; Milind Parab >> ; Swapnil Kashinath Jakhade >> ; Parshuram Raju Thombare >> >> Subject: Re: [PATCH v4 1/2] dt-bindings: pci: Retrain Link to work around >> Gen2 training defect. >> >> EXTERNAL MAIL >> >> >> On Fri, Dec 11, 2020 at 9:03 AM Nadeem Athani >> wrote: >>> >>> Cadence controller will not initiate autonomous speed change if >>> strapped as Gen2. The Retrain Link bit is set as quirk to enable this speed >> change. >>> Adding a quirk flag based on a new compatible string. >>> >>> Signed-off-by: Nadeem Athani >>> --- >>> Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml | 4 >>> +++- >>> 1 file changed, 3 insertions(+), 1 deletion(-) >>> >>> diff --git >>> a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml >>> b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml >>> index 293b8ec318bc..204d78f9efe3 100644 >>> --- a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml >>> +++ b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml >>> @@ -15,7 +15,9 @@ allOf: >>> >>> properties: >>>compatible: >>> -const: cdns,cdns-pcie-host >>> +enum: >>> +- cdns,cdns-pcie-host >>> +- cdns,cdns-pcie-host-quirk-retrain >> >> So, we'll just keep adding quirk strings on to the compatible? I don't think >> so. >> Compatible strings should map to a specific implementation/platform and >> quirks can then be implied from them. This is the only way we can implement >> quirks in the OS without firmware >> (DT) changes. > Ok, I will change the compatible string to " ti,j721e-pcie-host" in place of > " cdns,cdns-pcie-host-quirk-retrain" . > @Kishon Vijay Abraham I: Is this fine? Or will you suggest an appropriate > name? IMHO it should be something like "cdns,cdns-pcie-host-vX", since the quirk itself is not specific to TI platform rather Cadence IP version. Thank You, Kishon
linux-next: build failure after merge of the block tree
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 [-Werror=incompatible-pointer-types]
511 |trace_block_bio_remap(bdev_get_queue(rdev->bdev),
| ^~
| |
| struct request_queue *
In file included from include/trace/events/block.h:11,
from drivers/md/raid0.c:17:
include/trace/events/block.h:458:23: note: expected 'struct bio *' but argument
is of type 'struct request_queue *'
458 | TP_PROTO(struct bio *bio, dev_t dev, sector_t from),
| ^~~
include/linux/tracepoint.h:238:34: note: in definition of macro
'__DECLARE_TRACE'
238 | static inline void trace_##name(proto)\
| ^
include/linux/tracepoint.h:411:24: note: in expansion of macro 'PARAMS'
411 | __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args), \
|^~
include/linux/tracepoint.h:547:2: note: in expansion of macro 'DECLARE_TRACE'
547 | DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
| ^
include/linux/tracepoint.h:547:22: note: in expansion of macro 'PARAMS'
547 | DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
| ^~
include/trace/events/block.h:456:1: note: in expansion of macro 'TRACE_EVENT'
456 | TRACE_EVENT(block_bio_remap,
| ^~~
include/trace/events/block.h:458:2: note: in expansion of macro 'TP_PROTO'
458 | TP_PROTO(struct bio *bio, dev_t dev, sector_t from),
| ^~~~
drivers/md/raid0.c:512:5: warning: passing argument 2 of
'trace_block_bio_remap' makes integer from pointer without a cast
[-Wint-conversion]
512 | discard_bio, disk_devt(mddev->gendisk),
| ^~~
| |
| struct bio *
In file included from include/trace/events/block.h:11,
from drivers/md/raid0.c:17:
include/trace/events/block.h:458:34: note: expected 'dev_t' {aka 'unsigned
int'} but argument is of type 'struct bio *'
458 | TP_PROTO(struct bio *bio, dev_t dev, sector_t from),
|~~^~~
include/linux/tracepoint.h:238:34: note: in definition of macro
'__DECLARE_TRACE'
238 | static inline void trace_##name(proto)\
| ^
include/linux/tracepoint.h:411:24: note: in expansion of macro 'PARAMS'
411 | __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args), \
|^~
include/linux/tracepoint.h:547:2: note: in expansion of macro 'DECLARE_TRACE'
547 | DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
| ^
include/linux/tracepoint.h:547:22: note: in expansion of macro 'PARAMS'
547 | DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
| ^~
include/trace/events/block.h:456:1: note: in expansion of macro 'TRACE_EVENT'
456 | TRACE_EVENT(block_bio_remap,
| ^~~
include/trace/events/block.h:458:2: note: in expansion of macro 'TP_PROTO'
458 | TP_PROTO(struct bio *bio, dev_t dev, sector_t from),
| ^~~~
drivers/md/raid0.c:511:4: error: too many arguments to function
'trace_block_bio_remap'
511 |trace_block_bio_remap(bdev_get_queue(rdev->bdev),
|^
In file included from include/trace/events/block.h:11,
from drivers/md/raid0.c:17:
include/linux/tracepoint.h:238:21: note: declared here
238 | static inline void trace_##name(proto)\
| ^~
include/linux/tracepoint.h:411:2: note: in expansion of macro '__DECLARE_TRACE'
411 | __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args), \
| ^~~
include/linux/tracepoint.h:547:2: note: in expansion of macro 'DECLARE_TRACE'
547 | DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
| ^
include/trace/events/block.h:456:1: note: in expansion of macro 'TRACE_EVENT'
456 | TRACE_EVENT(block_bio_remap,
| ^~~
Caused by commit
1c02fca620f7 ("block: remove the request_queue argument to the
block_bio_remap tracepoint")
interacting with commit
57a0f3a81ef2 ("Revert "md: add md_submit_discard_bio() for submitting discard
bio"")
from Linus' tree.
I have applied the following merge fix:
From: Stephen Rothwell
Date: Mon, 14 Dec 2020 15:14:26 +1100
Subject: [PATCH] fixup for "block: remove the request_queue argument to the
block_bio_remap tracepoint"
conflicting with
"Revert "md: add md_submit_discard_bio() for submitting discard bio""
Signed-off-by: Stephen Rothwell
---
drivers/md/raid0.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c
index
Re: [PATCH 2/2] powerpc/64s: Trim offlined CPUs from mm_cpumasks
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
>> to manage its TLBs.
>>
>> However the exit_flush_lazy_tlbs() function expects that after
>> returning, all CPUs (except self) have flushed TLBs for that mm, in
>> which case TLBIEL can be used for this flush. This breaks for offline
>> CPUs because they don't get the IPI to flush their TLB. This can lead
>> to stale translations.
>>
>> Fix this by clearing the CPU from mm_cpumasks, then flushing all TLBs
>> before going offline.
>>
>> These offlined CPU bits stuck in the cpumask also prevents the cpumask
>> from being trimmed back to local mode, which means continual broadcast
>> IPIs or TLBIEs are needed for TLB flushing. This patch prevents that
>> situation too.
>>
>> Signed-off-by: Nicholas Piggin
>
> Thanks for your patch!
>
>> --- a/arch/powerpc/platforms/powermac/smp.c
>> +++ b/arch/powerpc/platforms/powermac/smp.c
>> @@ -911,6 +911,8 @@ static int smp_core99_cpu_disable(void)
>>
>> mpic_cpu_set_priority(0xf);
>>
>> + cleanup_cpu_mmu_context();
>> +
>
> I guess this change broke pmac32_defconfig+SMP in v5.10-rc7?
>
> arch/powerpc/platforms/powermac/smp.c: error: implicit
> declaration of function 'cleanup_cpu_mmu_context'
> [-Werror=implicit-function-declaration]: => 914:2
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/14423174/
Hey, yeah it does thanks for catching it. This patch fixes it for me
---
>From a9b5ec92ffac975e81c6d7db6ff2b1486b2723f7 Mon Sep 17 00:00:00 2001
From: Nicholas Piggin
Date: Mon, 14 Dec 2020 13:52:39 +1000
Subject: [PATCH] powerpc/32s: Fix cleanup_cpu_mmu_context() compile bug
32s has no tlbiel_all() defined, so just disable the cleanup with a
comment.
Fixes: 01b0f0eae081 ("powerpc/64s: Trim offlined CPUs from mm_cpumasks")
Reported-by: Geert Uytterhoeven
Signed-off-by: Nicholas Piggin
---
arch/powerpc/platforms/powermac/smp.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/platforms/powermac/smp.c
b/arch/powerpc/platforms/powermac/smp.c
index adae2a6712e1..66ef5f8f4445 100644
--- a/arch/powerpc/platforms/powermac/smp.c
+++ b/arch/powerpc/platforms/powermac/smp.c
@@ -911,7 +911,16 @@ static int smp_core99_cpu_disable(void)
mpic_cpu_set_priority(0xf);
+ /*
+* Would be nice for consistency if all platforms clear mm_cpumask and
+* flush TLBs on unplug, but the TLB invalidation bug described in
+* commit 01b0f0eae081 ("powerpc/64s: Trim offlined CPUs from
+* mm_cpumasks") only applies to 64s and for now we only have the TLB
+* flush code for that platform.
+*/
+#ifdef CONFIG_PPC64
cleanup_cpu_mmu_context();
+#endif
return 0;
}
--
2.23.0
Re: [PATCH 2/8] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode
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 code, but a significant complexity (which >> affects all archs) so needs a lot more review and testing at this >> point. > > I don't think it's ready for this merge window. Yes next one I meant (aka this one for development perspective :)). > I read the early > patches again, and I think they make the membarrier code worse, not > better. Mathieu and I disagree, so we are at an impasse. I addressed your comment about not being able to do the additional core sync avoidance from the exit tlb call (you can indeed do so in your arch code) and about exit_lazy_tlb being a call into the scheduler (it's not) and about the arch code not being able to reconcile lazy tlb mm with the core scheduler code (you can). I fundamentally think the core sync is an issue with what the membarrier / arch specifics are doing with lazy tlb mm switching, and not something the core scheduler needs to know about at all. I don't see the big problem with essentially moving it from an explicit call to exit_lazy_tlb (which from scheduler POV describes better what it is doing, not how). > I'm not fundamentally opposed to the shoot-lazies concept, > but it needs more thought and it needs a cleaner foundation. Well shoot lazies actually doesn't really rely on that membarrier change at all, it just came as a nice looking cleanup so that part can be dropped from the series. It's not really foundational. Thanks, Nick
Re: [PATCH v3] lib: stackdepot: Add support to configure STACK_HASH_SIZE
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 to configure STACK_HASH_SIZE.
Aim is to have configurable value for STACK_HASH_SIZE, so that one
can configure it depending on usecase there by reducing the static
memory overhead.
One example is of Page Owner, default value of STACK_HASH_SIZE lead
stack depot to consume 8MB of static memory. Making it configurable
and use lower value helps to enable features like CONFIG_PAGE_OWNER
without any significant overhead.
>>>
>>> Can we go with a static CONFIG_ parameter instead?
>>> Guess most users won't bother changing the default anyway, and for
>>> CONFIG_PAGE_OWNER users changing the size at boot time is not strictly
>>> needed.
>>>
>> Thanks for review.
>>
>> One advantage of having run time parameter is we can simply set it to a
>> lower value at runtime if page_owner=off thereby reducing the memory
>> usage or use default value if we want to use page owner so, we have some
>> some flexibility here. This is not possible with static parameter as we
>> have to have some predefined value.
>
> If we are talking about a configuration in which page_owner is the
> only stackdepot user in the system, then for page_owner=off it
> probably makes more sense to disable stackdepot completely instead of
> setting it to a lower value. This is a lot easier to do in terms of
> correctness.
> But if there are other users (e.g. KASAN), their stackdepot usage may
> actually dominate that of page_owner.
>
-static struct stack_record *stack_table[STACK_HASH_SIZE] = {
- [0 ... STACK_HASH_SIZE - 1] = NULL
+static unsigned int stack_hash_order = 20;
>>>
>>> Please initialize with MAX_STACK_HASH_ORDER instead.
>>>
>>
>> Sure, will update this.
>>
>
>
+
+static int __init init_stackdepot(void)
+{
+ size_t size = (STACK_HASH_SIZE * sizeof(struct stack_record *));
+
+ stack_table = vmalloc(size);
+ memcpy(stack_table, stack_table_def, size);
>>>
>>> Looks like you are assuming stack_table_def already contains some data
>>> by this point.
>>> But if STACK_HASH_SIZE shrinks this memcpy() above will just copy some
>>> part of the table, whereas the rest will be lost.
>>> We'll need to:
>>> - either explicitly decide we can afford losing this data (no idea how
>>> bad this can potentially be),
>>> - or disallow storing anything prior to full stackdepot initialization
>>> (then we don't need stack_table_def),
>>> - or carefully move all entries to the first part of the table.
>>>
>>> Alex
>>>
>>
>> The hash for stack_table_def is computed using the run time parameter
>> stack_hash_order, though stack_table_def is a bigger array it will only
>> use the entries that are with in the run time configured STACK_HASH_SIZE
>> range. so, there will be no data loss during copy.
>
> Do we expect any data to be stored into stack_table_def before
> setup_stack_hash_order() is called?
> If the answer is no, then we could probably drop stack_table_def and
> allocate the table right in setup_stack_hash_order()?
>
Yes, we do see an allocation from stack depot even before init is called
from kasan, thats the reason for having stack_table_def.
This is the issue reported due to that on v2, so i added stack_table_def.
https://lkml.org/lkml/2020/12/3/839
Thanks,
Vijay
>> Thanks,
>> Vijay
>>
>> --
>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
>> member of Code Aurora Forum, hosted by The Linux Foundation
>
>
>
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of Code Aurora Forum, hosted by The Linux Foundation
linux-next: manual merge of the block tree with the origin tree
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 block tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/md/raid10.c
index 3b598a3cb462,a84fa7526a53..
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@@ -1493,7 -1506,8 +1491,8 @@@ static void __make_request(struct mdde
r10_bio->mddev = mddev;
r10_bio->sector = bio->bi_iter.bi_sector;
r10_bio->state = 0;
+ r10_bio->read_slot = -1;
- memset(r10_bio->devs, 0, sizeof(r10_bio->devs[0]) *
conf->geo.raid_disks);
+ memset(r10_bio->devs, 0, sizeof(r10_bio->devs[0]) * conf->copies);
if (bio_data_dir(bio) == READ)
raid10_read_request(mddev, bio, r10_bio);
pgpPlwgYSIYiW.pgp
Description: OpenPGP digital signature
[PATCH] crypto: x86/crc32c-intel - Don't match some Zhaoxin CPUs
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 and Delete file test on partitions with
ext4 enabling metadata checksum, found using crc32c-generic driver
could get about 20% performance gain than using the driver crc32c-intel
on some Zhaoxin CPUs.
This case expect to use crc32c-generic driver for these Zhaoxin CPUs
to get performance gain, so remove these Zhaoxin CPUs support from
crc32c-intel.
Signed-off-by: Tony W Wang-oc
---
arch/x86/crypto/crc32c-intel_glue.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/x86/crypto/crc32c-intel_glue.c
b/arch/x86/crypto/crc32c-intel_glue.c
index feccb52..2cbbdde 100644
--- a/arch/x86/crypto/crc32c-intel_glue.c
+++ b/arch/x86/crypto/crc32c-intel_glue.c
@@ -215,6 +215,12 @@ static struct shash_alg alg = {
};
static const struct x86_cpu_id crc32c_cpu_id[] = {
+ X86_MATCH_VENDOR_FAM_FEATURE(ZHAOXIN, 0x6, X86_FEATURE_XMM4_2, 1),
+ X86_MATCH_VENDOR_FAM_MODEL_FEATURE(ZHAOXIN, 0x7, 0x1b,
X86_FEATURE_XMM4_2, 1),
+ X86_MATCH_VENDOR_FAM_MODEL_FEATURE(ZHAOXIN, 0x7, 0x3b,
X86_FEATURE_XMM4_2, 1),
+ X86_MATCH_VENDOR_FAM_FEATURE(CENTAUR, 0x6, X86_FEATURE_XMM4_2, 1),
+ X86_MATCH_VENDOR_FAM_MODEL_FEATURE(CENTAUR, 0x7, 0x1b,
X86_FEATURE_XMM4_2, 1),
+ X86_MATCH_VENDOR_FAM_MODEL_FEATURE(CENTAUR, 0x7, 0x3b,
X86_FEATURE_XMM4_2, 1),
X86_MATCH_FEATURE(X86_FEATURE_XMM4_2, NULL),
{}
};
@@ -222,7 +228,9 @@ MODULE_DEVICE_TABLE(x86cpu, crc32c_cpu_id);
static int __init crc32c_intel_mod_init(void)
{
- if (!x86_match_cpu(crc32c_cpu_id))
+ const struct x86_cpu_id *m = x86_match_cpu(crc32c_cpu_id);
+
+ if (!m || m->driver_data)
return -ENODEV;
#ifdef CONFIG_X86_64
if (boot_cpu_has(X86_FEATURE_PCLMULQDQ)) {
--
2.7.4
linux-next: manual merge of the block tree with Linus' tree
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
block_bio_remap tracepoint")
from the block tree.
I fixed it up (the former removed the code modified by the latter) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpZbpaLftKyV.pgp
Description: OpenPGP digital signature
[PATCH v2 0/2] UIO support for dfl devices
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 algorithem. The "driver_override" interface is abandoned, the DFL UIO driver matches any DFL device which could not be handled by other DFL drivers. So the DFL UIO driver could be used for new DFL devices which are not supported by kernel, also it will not impact the devices which are already got supported. Main changes from v1: - switch to the new matching algorithem. It matches DFL devices which could not be handled by other DFL drivers. - refacor the code about device resources filling. - add the documentation. Xu Yilun (2): fpga: dfl: add the userspace I/O device support for DFL devices Documentation: fpga: dfl: Add description for DFL UIO support Documentation/fpga/dfl.rst | 23 ++ drivers/fpga/Kconfig| 10 drivers/fpga/Makefile | 1 + drivers/fpga/dfl-uio-pdev.c | 108 drivers/fpga/dfl.c | 22 +++-- include/linux/dfl.h | 7 +++ 6 files changed, 166 insertions(+), 5 deletions(-) create mode 100644 drivers/fpga/dfl-uio-pdev.c -- 2.7.4
[PATCH v2 2/2] Documentation: fpga: dfl: Add description for DFL UIO support
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 b/Documentation/fpga/dfl.rst index 0404fe6..a15e81e 100644 --- a/Documentation/fpga/dfl.rst +++ b/Documentation/fpga/dfl.rst @@ -502,6 +502,29 @@ FME Partial Reconfiguration Sub Feature driver (see drivers/fpga/dfl-fme-pr.c) could be a reference. +UIO support for DFL devices +=== +The FPGA is open for users to be reprogramed with newly developed hardware +components. They could instantiate a new private feature in the DFL, and then +get a DFL device in their system. In some cases users may need a userspace +driver for the DFL device: + +* Users may need to run some diagnostic test for their hardwares. +* Some hardware is designed for specific purposes and does not fit into one of + the standard kernel subsystems. + +This requires the direct access to the MMIO space and interrupt handling in +userspace. We implemented a dfl-uio-pdev module which exposes the UIO device +interfaces. It adds the uio_pdrv_genirq platform device with the resources of +the DFL device, and let the generic UIO platform device driver provide UIO +support to userspace. + +The DFL UIO driver has a special matching algorithem. It will match any DFL +device which could not be handled by other DFL drivers. In this way, it will +not impact the functionality of the features which are already supported by the +system. + + Open discussion === FME driver exports one ioctl (DFL_FPGA_FME_PORT_PR) for partial reconfiguration -- 2.7.4
[PATCH V2 1/1] scsi: ufs: Fix a possible NULL pointer issue
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(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index c1c401b..ef155a9 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8883,8 +8883,11 @@ int ufshcd_system_suspend(struct ufs_hba *hba)
int ret = 0;
ktime_t start = ktime_get();
+ if (!hba)
+ return 0;
+
down(>eh_sem);
- if (!hba || !hba->is_powered)
+ if (!hba->is_powered)
return 0;
if ((ufs_get_pm_lvl_to_dev_pwr_mode(hba->spm_lvl) ==
@@ -8932,10 +8935,8 @@ int ufshcd_system_resume(struct ufs_hba *hba)
int ret = 0;
ktime_t start = ktime_get();
- if (!hba) {
- up(>eh_sem);
+ if (!hba)
return -EINVAL;
- }
if (!hba->is_powered || pm_runtime_suspended(hba->dev))
/*
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.
[PATCH v2 1/2] fpga: dfl: add the userspace I/O device support for DFL devices
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 provide support to userspace access to kernel
interrupts and memory locations.
The driver matches DFL devices in a different way. It has no device id
table, instead it matches any DFL device which could not be handled by
other DFL drivers. For this purpose, a match() ops is added to the dfl
driver, to allow dfl drivers have their own matching algorithem instead
of the standard id_table matching.
Signed-off-by: Xu Yilun
---
v2: switch to the new matching algorithem. It matches DFL devices which
could not be handled by other DFL drivers.
refacor the code about device resources filling.
fix some comments.
---
drivers/fpga/Kconfig| 10
drivers/fpga/Makefile | 1 +
drivers/fpga/dfl-uio-pdev.c | 108
drivers/fpga/dfl.c | 22 +++--
include/linux/dfl.h | 7 +++
5 files changed, 143 insertions(+), 5 deletions(-)
create mode 100644 drivers/fpga/dfl-uio-pdev.c
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 5d7f0ae..eb8a616 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -202,6 +202,16 @@ config FPGA_DFL_NIOS_INTEL_PAC_N3000
the card. It also instantiates the SPI master (spi-altera) for
the card's BMC (Board Management Controller).
+config FPGA_DFL_UIO_PDEV
+ tristate "FPGA DFL Driver for Userspace I/O platform devices"
+ depends on FPGA_DFL && UIO_PDRV_GENIRQ
+ help
+ Enable this to allow some DFL drivers be written in userspace. It
+ adds the uio_pdrv_genirq platform device with the DFL device's
+ resources, and lets the generic UIO platform device driver provide
+ support to userspace access to kernel interrupts and memory
+ locations.
+
config FPGA_DFL_PCI
tristate "FPGA DFL PCIe Device Driver"
depends on PCI && FPGA_DFL
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 18dc9885..e07b3d5 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -45,6 +45,7 @@ dfl-afu-objs := dfl-afu-main.o dfl-afu-region.o
dfl-afu-dma-region.o
dfl-afu-objs += dfl-afu-error.o
obj-$(CONFIG_FPGA_DFL_NIOS_INTEL_PAC_N3000)+= dfl-n3000-nios.o
+obj-$(CONFIG_FPGA_DFL_UIO_PDEV)+= dfl-uio-pdev.o
# Drivers for FPGAs which implement DFL
obj-$(CONFIG_FPGA_DFL_PCI) += dfl-pci.o
diff --git a/drivers/fpga/dfl-uio-pdev.c b/drivers/fpga/dfl-uio-pdev.c
new file mode 100644
index 000..68ede04
--- /dev/null
+++ b/drivers/fpga/dfl-uio-pdev.c
@@ -0,0 +1,108 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DFL driver for Userspace I/O platform devices
+ *
+ * Copyright (C) 2020 Intel Corporation, Inc.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME "dfl-uio-pdev"
+
+static struct dfl_driver dfl_uio_pdev_driver;
+
+static int check_for_other_drv_match(struct device_driver *drv, void *data)
+{
+ struct dfl_driver *ddrv = to_dfl_drv(drv);
+ struct dfl_device *ddev = data;
+
+ /* skip myself */
+ if (ddrv == _uio_pdev_driver)
+ return 0;
+
+ return dfl_match_device(ddev, ddrv);
+}
+
+static int dfl_uio_pdev_match(struct dfl_device *ddev)
+{
+ /*
+* If any other driver wants the device, leave the device to this other
+* driver.
+*/
+ if (bus_for_each_drv(_bus_type, NULL, ddev,
check_for_other_drv_match))
+ return 0;
+
+ return 1;
+}
+
+static int dfl_uio_pdev_probe(struct dfl_device *ddev)
+{
+ struct device *dev = >dev;
+ struct platform_device_info pdevinfo = { 0 };
+ struct uio_info uio_pdata = { 0 };
+ struct platform_device *uio_pdev;
+ struct resource *res;
+ int i;
+
+ pdevinfo.name = "uio_pdrv_genirq";
+
+ res = kcalloc(ddev->num_irqs + 1, sizeof(*res), GFP_KERNEL);
+ if (!res)
+ return -ENOMEM;
+
+ res[0].parent = >mmio_res;
+ res[0].flags = IORESOURCE_MEM;
+ res[0].start = ddev->mmio_res.start;
+ res[0].end = ddev->mmio_res.end;
+
+ /* then add irq resource */
+ for (i = 0; i < ddev->num_irqs; i++) {
+ res[i + 1].flags = IORESOURCE_IRQ;
+ res[i + 1].start = ddev->irqs[i];
+ res[i + 1].end = ddev->irqs[i];
+ }
+
+ uio_pdata.name = DRIVER_NAME;
+ uio_pdata.version = "0";
+
+ pdevinfo.res = res;
+ pdevinfo.num_res = ddev->num_irqs + 1;
+ pdevinfo.parent = >dev;
+ pdevinfo.id = PLATFORM_DEVID_AUTO;
+ pdevinfo.data = _pdata;
+ pdevinfo.size_data = sizeof(uio_pdata);
+
+ uio_pdev = platform_device_register_full();
+
Re: [PATCH v2 0/3] Release allocated periodic bandwidth data from reset_bandwidth()
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 {add|drop}_endpoint()
> > > hooks are defined. This patchset adds more hooks and releases all
> > > bandwidth data from reset_bandwidth() path, not drop_endpoint().
> > >
> > >
> > > Changes in v2:
> > > - fix a 0-day warning from unused variable
> > > - split one big patch into three patches
> > > - bugfix in hw flags
> > >
> > > Ikjoon Jang (3):
> > > usb: xhci-mtk: code cleanups in getting bandwidth table
> > > usb: xhci-mtk: delay association of tt and ep
> > > usb: xhci-mtk: fix unreleased bandwidth data
> > >
> > > drivers/usb/host/xhci-mtk-sch.c | 180
> > > drivers/usb/host/xhci-mtk.h | 13 +++
> > > drivers/usb/host/xhci.c | 9 ++
> > > 3 files changed, 133 insertions(+), 69 deletions(-)
> > Thanks for your patch, I'll test it and check it with our DE
>
> Thanks, I will upload v3.
> But I don't expect any logic changes from v2.
> Can you please give me feedback on v2 if you find anything?
Ok
>
> >
> > >
> >
Re: [PATCH -next] drivers: leds: simplify the return expression of register_nasgpio_led()
subject prefix should be leds: ss4200: simplify the return expression of register_nasgpio_led
[PATCH v1 4/4] devicetree: dtsi: rk3399-puma.dtsi, add "rockchip," vendor prefix
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 a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
index 4660416c8f38..b715e73f9749 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
@@ -146,7 +146,7 @@
_phy {
status = "okay";
- drive-impedance-ohm = <33>;
+ rockchip,drive-impedance-ohm = <33>;
};
{
--
2.20.1
[PATCH v1 2/4] phy: rockchip: emmc, add vendor prefix to optional dts properties
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 a/drivers/phy/rockchip/phy-rockchip-emmc.c
b/drivers/phy/rockchip/phy-rockchip-emmc.c
index 1e424f263e7a..2fdbc8495798 100644
--- a/drivers/phy/rockchip/phy-rockchip-emmc.c
+++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
@@ -377,13 +377,13 @@ static int rockchip_emmc_phy_probe(struct platform_device
*pdev)
rk_phy->enable_strobe_pulldown = PHYCTRL_REN_STRB_DISABLE;
rk_phy->output_tapdelay_select = PHYCTRL_OTAPDLYSEL_DEFAULT;
- if (!of_property_read_u32(dev->of_node, "drive-impedance-ohm", ))
+ if (!of_property_read_u32(dev->of_node, "rockchip,drive-impedance-ohm",
))
rk_phy->drive_impedance = convert_drive_impedance_ohm(pdev,
val);
- if (of_property_read_bool(dev->of_node, "enable-strobe-pulldown"))
+ if (of_property_read_bool(dev->of_node,
"rockchip,enable-strobe-pulldown"))
rk_phy->enable_strobe_pulldown = PHYCTRL_REN_STRB_ENABLE;
- if (!of_property_read_u32(dev->of_node, "output-tapdelay-select",
)) {
+ if (!of_property_read_u32(dev->of_node,
"rockchip,output-tapdelay-select", )) {
if (val <= PHYCTRL_OTAPDLYSEL_MAXVALUE)
rk_phy->output_tapdelay_select = val;
else
--
2.20.1
[PATCH v1 3/4] devicetree: dtsi: rk3399.dtsi, add "rockchip," vendor prefix
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 a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index f5dee5f447bb..38284686aab0 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi @@ -1482,7 +1482,7 @@ clock-names = "refclk"; #phy-cells = <1>; resets = < SRST_PCIEPHY>; - drive-impedance-ohm = <50>; + rockchip,drive-impedance-ohm = <50>; reset-names = "phy"; status = "disabled"; }; -- 2.20.1
[PATCH v1 0/4] rockchip: emmc: rk3399 add vendor prefix
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 --- Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt | 19 ++- arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 2 +- arch/arm64/boot/dts/rockchip/rk3399.dtsi| 2 +- drivers/phy/rockchip/phy-rockchip-emmc.c| 6 +++--- 4 files changed, 15 insertions(+), 14 deletions(-)
[PATCH v1 1/4] devicetree: phy: rockchip-emmc optional add vendor prefix
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 a/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
b/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
index 00aa2d349e55..3a55d8086868 100644
--- a/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
+++ b/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
@@ -13,14 +13,15 @@ Optional properties:
access to it), it is strongly suggested.
See ../clock/clock-bindings.txt for details.
- clocks: Should have a phandle to the card clock exported by the SDHCI
driver.
- - drive-impedance-ohm: Specifies the drive impedance in Ohm.
-Possible values are 33, 40, 50, 66 and 100.
-If not set, the default value of 50 will be applied.
- - enable-strobe-pulldown: Enable internal pull-down for the strobe line.
- If not set, pull-down is not used.
- - output-tapdelay-select: Specifies the phyctrl_otapdlysec register.
- If not set, the register defaults to 0x4.
- Maximum value 0xf.
+ - rockchip,drive-impedance-ohm: Specifies the drive impedance in Ohm.
+ Possible values are 33, 40, 50, 66 and 100.
+ If not set, the default value of 50 will be
+ applied.
+ - rockchip,enable-strobe-pulldown: Enable internal pull-down for the strobe
+line. If not set, pull-down is not used.
+ - rockchip,output-tapdelay-select: Specifies the phyctrl_otapdlysec register.
+If not set, the register defaults to 0x4.
+Maximum value 0xf.
Example:
@@ -37,7 +38,7 @@ grf: syscon@ff77 {
reg = <0xf780 0x20>;
clocks = <>;
clock-names = "emmcclk";
- drive-impedance-ohm = <50>;
+ rockchip,drive-impedance-ohm = <50>;
#phy-cells = <0>;
};
};
--
2.20.1
Re: [PATCH 0/3] rockchip: emmc: rk3399 add vendor prefix
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 --- Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt | 19 ++- arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 2 +- arch/arm64/boot/dts/rockchip/rk3399.dtsi| 2 +- drivers/phy/rockchip/phy-rockchip-emmc.c| 6 +++--- 4 files changed, 15 insertions(+), 14 deletions(-) Sorry send incomplete patch-set accidentally v1 follow. Chris
linux-next: manual merge of the drm tree with the crypto tree
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.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc MAINTAINERS
index 3b358262de8f,eb18459c1d16..
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -6932,11 -6913,16 +6941,10 @@@ S: Maintaine
W:http://floatingpoint.sourceforge.net/emulator/index.html
F:arch/x86/math-emu/
-FRAME RELAY DLCI/FRAD (Sangoma drivers too)
-L:net...@vger.kernel.org
-S:Orphan
-F:drivers/net/wan/dlci.c
-F:drivers/net/wan/sdla.c
-
FRAMEBUFFER LAYER
- M:Bartlomiej Zolnierkiewicz
L:dri-de...@lists.freedesktop.org
L:linux-fb...@vger.kernel.org
- S:Maintained
+ S:Orphan
Q:http://patchwork.kernel.org/project/linux-fbdev/list/
T:git git://anongit.freedesktop.org/drm/drm-misc
F:Documentation/fb/
@@@ -8985,16 -8962,13 +8993,23 @@@ M: Deepak Saxena
+ M:Edmund Dea
+ S:Maintained
+ F:Documentation/devicetree/bindings/display/intel,kmb_display.yaml
+ F:drivers/gpu/drm/kmb/
+
+INTEL KEEM BAY OCS AES/SM4 CRYPTO DRIVER
+M:Daniele Alessandrelli
+S:Maintained
+F:Documentation/devicetree/bindings/crypto/intel,keembay-ocs-aes.yaml
+F:drivers/crypto/keembay/Kconfig
+F:drivers/crypto/keembay/Makefile
+F:drivers/crypto/keembay/keembay-ocs-aes-core.c
+F:drivers/crypto/keembay/ocs-aes.c
+F:drivers/crypto/keembay/ocs-aes.h
+
INTEL MANAGEMENT ENGINE (mei)
M:Tomas Winkler
L:linux-kernel@vger.kernel.org
pgpqwJvtTv5Nl.pgp
Description: OpenPGP digital signature
[tip:irq/core] BUILD REGRESSION 3bda84519c6c2d57e7378417ac116f61d50abae1
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core branch HEAD: 3bda84519c6c2d57e7378417ac116f61d50abae1 genirq: Reexport irq_to_desc() for PPC KVM Error/Warning reports: https://lore.kernel.org/lkml/202012140602.bcg2ue7n-...@intel.com Error/Warning in current branch: ERROR: modpost: ".irq_to_desc" [arch/powerpc/kvm/kvm-hv.ko] undefined! Error/Warning ids grouped by kconfigs: gcc_recent_errors `-- powerpc-allmodconfig `-- ERROR:irq_to_desc-arch-powerpc-kvm-kvm-hv.ko-undefined elapsed time: 772m configs tested: 104 configs skipped: 2 gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig sh kfr2r09-romimage_defconfig sh microdev_defconfig mipsbcm47xx_defconfig powerpcmpc7448_hpc2_defconfig sh lboxre2_defconfig arm h3600_defconfig arc nsimosci_hs_smp_defconfig shsh7785lcr_defconfig arm alldefconfig arc axs101_defconfig sh urquell_defconfig shdreamcast_defconfig arm colibri_pxa300_defconfig sh apsh4a3a_defconfig c6x dsk6455_defconfig powerpc sbc8548_defconfig sparc sparc64_defconfig powerpc sequoia_defconfig mipsmalta_kvm_guest_defconfig c6xevmc6678_defconfig mipsbcm63xx_defconfig arm eseries_pxa_defconfig m68km5307c3_defconfig powerpc wii_defconfig sh se7780_defconfig powerpc ebony_defconfig m68k sun3x_defconfig m68k m5275evb_defconfig xtensa audio_kc705_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a001-20201213 i386 randconfig-a004-20201213 i386 randconfig-a003-20201213 i386 randconfig-a002-20201213 i386 randconfig-a005-20201213 i386 randconfig-a006-20201213 x86_64 randconfig-a003-20201213 x86_64 randconfig-a006-20201213 x86_64 randconfig-a002-20201213 x86_64 randconfig-a005-20201213 x86_64 randconfig-a004-20201213 x86_64 randconfig-a001-20201213 i386 randconfig-a014-20201213 i386 randconfig-a013-20201213 i386 randconfig-a012-20201213 i386 randconfig-a011-20201213 i386 randconfig-a016-20201213 i386 randconfig-a015-20201213 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselfte
[PATCH RESEND v5 2/2] NFSv4: Refactor to use user namespaces for nfs4idmap
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 were only such that the userspace facing side of the filesystem (superblock s_user_ns) could be set to a non init user namespace. This furthers the fs_context related refactoring, and piggybacks on top of that logic, so the superblock user namespace, and the NFS user namespace are the same. Users can still use rpc.idmapd if they choose to, but there are complexities with user namespaces and request-key that have yet to be addresssed. Eventually, we will need to at least: * Separate out the keyring cache by namespace * Come up with an upcall mechanism that can be triggered inside of the container, or safely triggered outside, with the requisite context to do the right mapping. * Handle whatever refactoring needs to be done in net/sunrpc. Signed-off-by: Sargun Dhillon Tested-by: Alban Crequy --- fs/nfs/nfs4client.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c index be7915c861ce..86acffe7335c 100644 --- a/fs/nfs/nfs4client.c +++ b/fs/nfs/nfs4client.c @@ -1153,7 +1153,7 @@ struct nfs_server *nfs4_create_server(struct fs_context *fc) if (!server) return ERR_PTR(-ENOMEM); - server->cred = get_cred(current_cred()); + server->cred = get_cred(fc->cred); auth_probe = ctx->auth_info.flavor_len < 1; -- 2.25.1
[PATCH RESEND v5 0/2] NFS: Fix interaction between fs_context and user namespaces
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 UIDs
being sent to the server are different than the local UIDs being checked.
This can cause "breakage", where if you try to communicate with the NFS
server with any other set of mappings, it breaks.
The reason for this is that you can call fsopen("nfs4") in the unprivileged
namespace, and that configures fs_context with all the right information
for that user namespace. In addition, it also keeps a gets a cred object
associated with the caller -- which should match the user namespace.
Unfortunately, the mount has to be finished in the init_user_ns because we
currently require CAP_SYS_ADMIN in the init user namespace to call fsmount.
This means that the superblock's user namespace is set "correctly" to the
container, but there's absolutely no way nfs4idmap to consume an
unprivileged user namespace because the cred / user_ns that's passed down
to nfs4idmap is the one at fsmount.
How this actually exhibits is let's say that the UID 0 in the user
namespace is mapped to UID 1000 in the init user ns (and kuid space). What
will happen is that nfs4idmap will translate the UID 1000 into UID 0 on the
wire, even if the mount is in entirely in the mount / user namespace of the
container.
So, it looks something like this
Client in unprivileged User NS (UID: 0, KUID: 0)
->Perform open()
...VFS / NFS bits...
nfs_map_uid_to_name ->
from_kuid_munged(init_user_ns, uid) (returns 0)
RPC with UID 0
This behaviour happens "the other way" as well, where the UID in the
container may be 0, but the corresponding kuid is 1000. When a response
from an NFS server comes in we decode it according to the idmap userns.
The way this exhibits is even more odd.
Server responds with file attribute (UID: 0, GID: 0)
->nfs_map_name_to_uid(..., 0)
->make_kuid(init_user_ns, id) (returns 0)
VFS / NFS Bits...
->from_kuid(container_ns, 0) -> invalid uid
-> EOVERFLOW
This changes the nfs server to use the cred / userns from fs_context, which
is how idmap is constructed. This subsequently is used in the above
described flow of converting uids back-and-forth.
Trond gave the feedback that this behaviour [implemented by this patch] is
how the legacy sys_mount() behaviour worked[1], and that the intended
behaviour is for UIDs to be plumbed through entirely, where the user
namespaces UIDs are what is sent over the wire, and not the init user ns.
[1]:
https://lore.kernel.org/linux-nfs/8feccf45f6575a204da03e796391cc135283eb88.ca...@hammerspace.com/
[2]: https://lore.kernel.org/linux-nfs/20201112100952.3514-1-sar...@sargun.me/
Sargun Dhillon (2):
NFS: NFSv2/NFSv3: Use cred from fs_context during mount
NFSv4: Refactor to use user namespaces for nfs4idmap
fs/nfs/client.c | 4 ++--
fs/nfs/nfs4client.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--
2.25.1
[PATCH RESEND v5 1/2] NFS: NFSv2/NFSv3: Use cred from fs_context during mount
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 during fsopen is used as well as the net_ns. NFS has already had a number of changes to prepare it for user namespaces: 1a58e8a0e5c1: NFS: Store the credential of the mount process in the nfs_server 264d948ce7d0: NFS: Convert NFSv3 to use the container user namespace c207db2f5da5: NFS: Convert NFSv2 to use the container user namespace Previously, different credentials could be used for creation of the fs_context versus creation of the nfs_server, as FSCONFIG_CMD_CREATE did the actual credential check, and that's where current_creds() were fetched. This meant that the user namespace which fsopen was called in could be a non-init user namespace. This still requires that the user that calls FSCONFIG_CMD_CREATE has CAP_SYS_ADMIN in the init user ns. This roughly allows a privileged user to mount on behalf of an unprivileged usernamespace, by forking off and calling fsopen in the unprivileged user namespace. It can then pass back that fsfd to the privileged process which can configure the NFS mount, and then it can call FSCONFIG_CMD_CREATE before switching back into the mount namespace of the container, and finish up the mounting process and call fsmount and move_mount. Signed-off-by: Sargun Dhillon Tested-by: Alban Crequy --- fs/nfs/client.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/nfs/client.c b/fs/nfs/client.c index 4b8cc93913f7..1e6f3b3ed445 100644 --- a/fs/nfs/client.c +++ b/fs/nfs/client.c @@ -571,7 +571,7 @@ static int nfs_start_lockd(struct nfs_server *server) 1 : 0, .net= clp->cl_net, .nlmclnt_ops= clp->cl_nfs_mod->rpc_ops->nlmclnt_ops, - .cred = current_cred(), + .cred = server->cred, }; if (nlm_init.nfs_version > 3) @@ -985,7 +985,7 @@ struct nfs_server *nfs_create_server(struct fs_context *fc) if (!server) return ERR_PTR(-ENOMEM); - server->cred = get_cred(current_cred()); + server->cred = get_cred(fc->cred); error = -ENOMEM; fattr = nfs_alloc_fattr(); -- 2.25.1
[PATCH 3/3] devicetree: dtsi: rk3399-puma.dtsi, add "rockchip," vendor prefix
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 a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
index 4660416c8f38..b715e73f9749 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
@@ -146,7 +146,7 @@
_phy {
status = "okay";
- drive-impedance-ohm = <33>;
+ rockchip,drive-impedance-ohm = <33>;
};
{
--
2.20.1
[PATCH 2/3] devicetree: dtsi: rk3399.dtsi, add "rockchip," vendor prefix
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 a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index f5dee5f447bb..38284686aab0 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi @@ -1482,7 +1482,7 @@ clock-names = "refclk"; #phy-cells = <1>; resets = < SRST_PCIEPHY>; - drive-impedance-ohm = <50>; + rockchip,drive-impedance-ohm = <50>; reset-names = "phy"; status = "disabled"; }; -- 2.20.1
[PATCH 0/3] rockchip: emmc: rk3399 add vendor prefix
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 ++- arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 2 +- arch/arm64/boot/dts/rockchip/rk3399.dtsi| 2 +- drivers/phy/rockchip/phy-rockchip-emmc.c| 6 +++--- 4 files changed, 15 insertions(+), 14 deletions(-)
[PATCH 1/3] phy: rockchip: emmc, add vendor prefix to optional dts properties
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 a/drivers/phy/rockchip/phy-rockchip-emmc.c
b/drivers/phy/rockchip/phy-rockchip-emmc.c
index 1e424f263e7a..2fdbc8495798 100644
--- a/drivers/phy/rockchip/phy-rockchip-emmc.c
+++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
@@ -377,13 +377,13 @@ static int rockchip_emmc_phy_probe(struct platform_device
*pdev)
rk_phy->enable_strobe_pulldown = PHYCTRL_REN_STRB_DISABLE;
rk_phy->output_tapdelay_select = PHYCTRL_OTAPDLYSEL_DEFAULT;
- if (!of_property_read_u32(dev->of_node, "drive-impedance-ohm", ))
+ if (!of_property_read_u32(dev->of_node, "rockchip,drive-impedance-ohm",
))
rk_phy->drive_impedance = convert_drive_impedance_ohm(pdev,
val);
- if (of_property_read_bool(dev->of_node, "enable-strobe-pulldown"))
+ if (of_property_read_bool(dev->of_node,
"rockchip,enable-strobe-pulldown"))
rk_phy->enable_strobe_pulldown = PHYCTRL_REN_STRB_ENABLE;
- if (!of_property_read_u32(dev->of_node, "output-tapdelay-select",
)) {
+ if (!of_property_read_u32(dev->of_node,
"rockchip,output-tapdelay-select", )) {
if (val <= PHYCTRL_OTAPDLYSEL_MAXVALUE)
rk_phy->output_tapdelay_select = val;
else
--
2.20.1
RE: [PATCH v2 5/5] dt-bindings: aspeed-lpc: Remove LPC partitioning
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 > Cc: Ryan Chen ; Lee Jones > ; Corey Minyard ; Arnd Bergmann > ; Greg Kroah-Hartman ; Linus > Walleij ; Haiyue Wang > ; Cyril Bur ; Robert > Lippert ; linux-arm-ker...@lists.infradead.org; > linux-asp...@lists.ozlabs.org; linux-kernel@vger.kernel.org; > open...@lists.ozlabs.org; linux-g...@vger.kernel.org > Subject: Re: [PATCH v2 5/5] dt-bindings: aspeed-lpc: Remove LPC partitioning > > Hi Wang Chia-Wei, > > On Mon, 5 Oct 2020, at 18:58, Chia-Wei, Wang wrote: > > The LPC controller has no concept of the BMC and the Host partitions. > > This patch fixes the documentation by removing the description on LPC > > partitions. The register offsets illustrated in the DTS node examples > > are also fixed to adapt to the LPC DTS change. > > > > Signed-off-by: Chia-Wei, Wang > > The documentation at [1] suggests this should probably be patch 1/5 rather > than 5/5, so if you send the series again I'd probably rearrange it. > Following the > steps outlined in [1] helps catch Rob's attention in the right way :) > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Docume > ntation/devicetree/bindings/submitting-patches.rst?h=v5.9 > > Rob: > > The changes here go some way towards cleaning up mistakes I made in the > Aspeed LPC controller binding. The proposed change is very much not > backwards compatible, but Joel and I don't want to live with the resulting > mess > in the drivers of catering to both layouts. Another way we could avoid the > driver mess is to rev all the bindings and immediately drop support for the > old > compatibles in the drivers. This creates a bit more churn in the bindings. > What > are you willing to accommodate? > > All consumers I'm aware of ship the Aspeed BMC dtb in FIT images alongside > the kernel, so while backwards-incompatible changes are rightly frowned upon > I feel we probably wouldn't cause too much damage if we went that path. > > Andrew > > > --- > > .../devicetree/bindings/mfd/aspeed-lpc.txt| 85 +++ > > 1 file changed, 14 insertions(+), 71 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt > > b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt > > index a92acf1dd491..866f54a09e09 100644 > > --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt > > +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt > > @@ -9,13 +9,7 @@ primary use case of the Aspeed LPC controller is as a > > slave on the bus conditions it can also take the role of bus master. > > > > The LPC controller is represented as a multi-function device to > > account for the -mix of functionality it provides. The principle split > > is between the register -layout at the start of the I/O space which > > is, to quote the Aspeed datasheet, -"basically compatible with the > > [LPC registers from the] popular BMC controller -H8S/2168[1]", and > > everything else, where everything else is an eclectic -collection of > > functions with a esoteric register layout. "Everything else", -here > > labeled the "host" portion of the controller, includes, but is not > > limited > > -to: > > +mix of functionality, which includes, but is not limited to: > > > > * An IPMI Block Transfer[2] Controller > > > > @@ -44,8 +38,8 @@ Required properties > > === > > > > - compatible: One of: > > - "aspeed,ast2400-lpc", "simple-mfd" > > - "aspeed,ast2500-lpc", "simple-mfd" > > + "aspeed,ast2400-lpc", "simple-mfd", "syscon" > > + "aspeed,ast2500-lpc", "simple-mfd", "syscon" > > > > - reg: contains the physical address and length values of the > > Aspeed > > LPC memory region. > > @@ -55,66 +49,17 @@ Required properties > > - ranges: Maps 0 to the physical address and length of the LPC memory > > region > > > > -Required LPC Child nodes > > - > > - > > -BMC Node > > - > > - > > -- compatible: One of: > > - "aspeed,ast2400-lpc-bmc" > > - "aspeed,ast2500-lpc-bmc" > > - > > -- reg: contains the physical address and length values of the > > -H8S/2168-compatible LPC controller memory region > > - > > -Host Node > > -- > > - > > -- compatible: One of: > > - "aspeed,ast2400-lpc-host", "simple-mfd", "syscon" > > - "aspeed,ast2500-lpc-host", "simple-mfd", "syscon" > > - > > -- reg: contains the address and length values of the > > host-related > > -register space for the Aspeed LPC controller > > - > > -- #address-cells: <1> > > -- #size-cells: <1> > > -- ranges: Maps 0 to the address and
Re: [PATCH] crypto: x86/crc32c-intel - Don't match some Zhaoxin CPUs
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 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. This case expect to use crc32c-generic driver for some Zhaoxin CPUs to get performance gain, So remove these Zhaoxin CPUs support from crc32c-intel. Signed-off-by: Tony W Wang-oc >>> >>> Does this mean that the performance of the crc32c instruction on those CPUs >>> is >>> actually slower than a regular C implementation? That's very weird. >>> >> >> This driver does not use CRC instructions, but carryless >> multiplication and aggregation. So I suppose the pclmulqdq instruction >> triggers some pathological performance limitation here. >> > > Just noticed it uses both crc instructions and pclmulqdq instructions. > Sorry for the noise. > >> That means the crct10dif driver probably needs the same treatment. > > Tony, can you confirm that the problem is in the CRC instructions and > not in the PCLMULQDQ code path that supersedes it when available? CRC instructions. sincerely Tony
Re: [PATCH] crypto: x86/crc32c-intel - Don't match some Zhaoxin CPUs
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 registered, system will >> use crc32c-intel because its .cra_priority is greater than >> crc32c-generic. This case expect to use crc32c-generic driver for >> some Zhaoxin CPUs to get performance gain, So remove these Zhaoxin >> CPUs support from crc32c-intel. >> >> Signed-off-by: Tony W Wang-oc > > Does this mean that the performance of the crc32c instruction on those CPUs is > actually slower than a regular C implementation? That's very weird. > >From the lmbench3 Create and Delete file test on those chips, I think yes. sincerely Tony
[PATCH] blktrace: fix 'BUG: sleeping function called from invalid context' in case of PREEMPT_RT
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 raw_spin_lock().
Cc: Christoph Hellwig
Cc: Steven Rostedt
Cc: Ingo Molnar
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ming Lei
---
kernel/trace/blktrace.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
index 2c5b3c5317c2..53dc876d669d 100644
--- a/kernel/trace/blktrace.c
+++ b/kernel/trace/blktrace.c
@@ -34,7 +34,7 @@ static struct trace_array *blk_tr;
static bool blk_tracer_enabled __read_mostly;
static LIST_HEAD(running_trace_list);
-static __cacheline_aligned_in_smp DEFINE_SPINLOCK(running_trace_lock);
+static __cacheline_aligned_in_smp DEFINE_RAW_SPINLOCK(running_trace_lock);
/* Select an alternative, minimalistic output than the original one */
#define TRACE_BLK_OPT_CLASSIC 0x1
@@ -121,12 +121,12 @@ static void trace_note_tsk(struct task_struct *tsk)
struct blk_trace *bt;
tsk->btrace_seq = blktrace_seq;
- spin_lock_irqsave(_trace_lock, flags);
+ raw_spin_lock_irqsave(_trace_lock, flags);
list_for_each_entry(bt, _trace_list, running_list) {
trace_note(bt, tsk->pid, BLK_TN_PROCESS, tsk->comm,
sizeof(tsk->comm), 0);
}
- spin_unlock_irqrestore(_trace_lock, flags);
+ raw_spin_unlock_irqrestore(_trace_lock, flags);
}
static void trace_note_time(struct blk_trace *bt)
@@ -669,9 +669,9 @@ static int __blk_trace_startstop(struct request_queue *q,
int start)
blktrace_seq++;
smp_mb();
bt->trace_state = Blktrace_running;
- spin_lock_irq(_trace_lock);
+ raw_spin_lock_irq(_trace_lock);
list_add(>running_list, _trace_list);
- spin_unlock_irq(_trace_lock);
+ raw_spin_unlock_irq(_trace_lock);
trace_note_time(bt);
ret = 0;
@@ -679,9 +679,9 @@ static int __blk_trace_startstop(struct request_queue *q,
int start)
} else {
if (bt->trace_state == Blktrace_running) {
bt->trace_state = Blktrace_stopped;
- spin_lock_irq(_trace_lock);
+ raw_spin_lock_irq(_trace_lock);
list_del_init(>running_list);
- spin_unlock_irq(_trace_lock);
+ raw_spin_unlock_irq(_trace_lock);
relay_flush(bt->rchan);
ret = 0;
}
--
2.28.0
linux-next: build failure after merge of the net-next tree
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'?
[-Werror=implicit-function-declaration]
450 |nla_strlcpy(name, info->attrs[CIFS_GENL_ATTR_SWN_RESOURCE_NAME],
|^~~
|nla_strscpy
Caused by commit
872f69034194 ("treewide: rename nla_strlcpy to nla_strscpy.")
interacting with commit
27228d73f4d2 ("cifs: Set witness notification handler for messages from
userspace daemon")
from the cifs tree.
I have applied the following merge fix patch.
From: Stephen Rothwell
Date: Mon, 14 Dec 2020 13:09:27 +1100
Subject: [PATCH] fixup for "treewide: rename nla_strlcpy to nla_strscpy."
conflicting with
"cifs: Set witness notification handler for messages from userspace daemon"
Signed-off-by: Stephen Rothwell
---
fs/cifs/cifs_swn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/cifs/cifs_swn.c b/fs/cifs/cifs_swn.c
index 642c9eedc8ab..d762d442dfa5 100644
--- a/fs/cifs/cifs_swn.c
+++ b/fs/cifs/cifs_swn.c
@@ -447,7 +447,7 @@ int cifs_swn_notify(struct sk_buff *skb, struct genl_info
*info)
int state;
if (info->attrs[CIFS_GENL_ATTR_SWN_RESOURCE_NAME]) {
- nla_strlcpy(name,
info->attrs[CIFS_GENL_ATTR_SWN_RESOURCE_NAME],
+ nla_strscpy(name,
info->attrs[CIFS_GENL_ATTR_SWN_RESOURCE_NAME],
sizeof(name));
} else {
cifs_dbg(FYI, "%s: missing resource name attribute\n",
__func__);
--
2.29.2
--
Cheers,
Stephen Rothwell
pgpwNJVWboDD5.pgp
Description: OpenPGP digital signature
[PATCH 1/1] scsi: ufs: Fix a possible NULL pointer issue
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(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index c1c401b..140394a 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8883,9 +8883,13 @@ int ufshcd_system_suspend(struct ufs_hba *hba)
int ret = 0;
ktime_t start = ktime_get();
- down(>eh_sem);
- if (!hba || !hba->is_powered)
+ if (!hba)
+ return 0;
+
+ if (!hba->is_powered) {
+ down(>eh_sem);
return 0;
+ }
if ((ufs_get_pm_lvl_to_dev_pwr_mode(hba->spm_lvl) ==
hba->curr_dev_pwr_mode) &&
@@ -8932,10 +8936,8 @@ int ufshcd_system_resume(struct ufs_hba *hba)
int ret = 0;
ktime_t start = ktime_get();
- if (!hba) {
- up(>eh_sem);
+ if (!hba)
return -EINVAL;
- }
if (!hba->is_powered || pm_runtime_suspended(hba->dev))
/*
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.
Re: [PATCH v12 00/31] Speculative page faults
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 those high-TLP ones, > > > > > > # launch time of applications(s): > > > > > > package version w/ SPF w/o SPF improve(%) > > > -- > > > Baidu maps10.13.3 0.887 0.98 9.49 > > > Taobao8.4.0.35 1.227 1.2935.10 > > > Meituan 9.12.401 1.107 1.54328.26 > > > WeChat7.0.32.353 2.68 12.20 > > > Honor of Kings1.43.1.6 6.636.7131.24 > > > > That's great news, thanks for reporting this! > > > > > > > > By the way, we have verified our platforms with those patches and > > > achieved the goal of mass production. > > > > Another good news! > > For my information, what is your targeted hardware? > > > > Cheers, > > Laurent. > > Hi Laurent, > > Our targeted hardware belongs to ARM64 multi-core series. Hello! I was trying to develop an intuition about why does SPF give improvement for you on small CPU systems. This is just a high-level theory but: 1. Assume the improvement is because of elimination of "blocking" on mmap_sem. Could it be that the mmap_sem is acquired in write-mode unnecessarily in some places, thus causing blocking on mmap_sem in other paths? If so, is it feasible to convert such usages to acquiring them in read-mode? 2. Assume the improvement is because of lesser read-side contention on mmap_sem. On small CPU systems, I would not expect reducing cache-line bouncing to give such a dramatic improvement in performance as you are seeing. Thanks for any insight on this! - Joel
[tip:master] BUILD SUCCESS 68ae68af2ba73b2969f2ce617b09b25bcbd74dd8
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master branch HEAD: 68ae68af2ba73b2969f2ce617b09b25bcbd74dd8 Merge branch 'timers/core' elapsed time: 723m configs tested: 110 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig arc axs101_defconfig sh urquell_defconfig shdreamcast_defconfig sh se7206_defconfig mips decstation_defconfig arm omap1_defconfig powerpc holly_defconfig arc tb10x_defconfig powerpc ps3_defconfig i386 alldefconfig arm imx_v6_v7_defconfig powerpc ppc40x_defconfig armoxnas_v6_defconfig powerpc mpc85xx_cds_defconfig powerpc motionpro_defconfig armshmobile_defconfig nds32 allnoconfig powerpc obs600_defconfig sh j2_defconfig armu300_defconfig mipsmalta_kvm_guest_defconfig c6xevmc6678_defconfig mipsbcm63xx_defconfig h8300 h8s-sim_defconfig nios2allyesconfig powerpcmpc7448_hpc2_defconfig mips loongson3_defconfig microblaze mmu_defconfig arm eseries_pxa_defconfig m68km5307c3_defconfig powerpc wii_defconfig sh se7780_defconfig powerpc ebony_defconfig sh apsh4a3a_defconfig m68k sun3x_defconfig m68k m5275evb_defconfig xtensa audio_kc705_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig c6x allyesconfig nds32 defconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc 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 randconfig-a004-20201213 x86_64 randconfig-a001-20201213 i386 randconfig-a001-20201213 i386 randconfig-a004-20201213 i386 randconfig-a003-20201213 i386 randconfig-a002-20201213 i386 randconfig-a005-20201213 i386 randconfig-a006-20201213 i386 randconfig-a014-20201213 i386 randconfig-a013-20201213 i386 randconfig-a012-20201213 i386 randconfig-a011-20201213 i386 randconfig-a016-20201213 i386 randconfig-a015-20201213 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64
Re: [PATCH v2 14/21] phy: sun4i-usb: Rework "pmu_unk1" handling
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 that is cleared is
> called SUNXI_HCI_PHY_CTRL_SIDDQ in the BSP (similar to
> the USBC_PHY_CTL_SIDDQ we cleared for main PHYCTL).
Oh, right, somehow I failed to find this in the BSP, I guess I got
confused over that similar symbol. I will put proper names to it.
Thanks!
Andre
>>
>> Generalise the existing code by allowing configs to specify a bitmask
>> of bits to clear.
>>
>> Signed-off-by: Andre Przywara
>> ---
>> drivers/phy/allwinner/phy-sun4i-usb.c | 28 +++
>>
>> 1 file changed, 11 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c
>> b/drivers/phy/allwinner/phy-sun4i-usb.c
>> index 651d5e2a25ce..4ba0699e0bb4 100644
>> --- a/drivers/phy/allwinner/phy-sun4i-usb.c
>> +++ b/drivers/phy/allwinner/phy-sun4i-usb.c
>> @@ -115,9 +115,9 @@ struct sun4i_usb_phy_cfg {
>> int hsic_index;
>> enum sun4i_usb_phy_type type;
>> u32 disc_thresh;
>> +u32 pmu_unk1_clrbits;
>> u8 phyctl_offset;
>> bool dedicated_clocks;
>> -bool enable_pmu_unk1;
>> bool phy0_dual_route;
>> int missing_phys;
>> };
>> @@ -288,6 +288,12 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>> return ret;
>> }
>>
>> +if (phy->pmu && data->cfg->pmu_unk1_clrbits) {
>> +val = readl(phy->pmu + REG_PMU_UNK1);
>> +val &= ~data->cfg->pmu_unk1_clrbits;
>> +writel(val, phy->pmu + REG_PMU_UNK1);
>> +}
>> +
>> if (data->cfg->type == sun8i_a83t_phy ||
>> data->cfg->type == sun50i_h6_phy) {
>> if (phy->index == 0) {
>> @@ -297,11 +303,6 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>> writel(val, data->base + data->cfg-
>>> phyctl_offset);
>> }
>> } else {
>> -if (phy->pmu && data->cfg->enable_pmu_unk1) {
>> -val = readl(phy->pmu + REG_PMU_UNK1);
>> -writel(val & ~2, phy->pmu + REG_PMU_UNK1);
>> -}
>> -
>> /* Enable USB 45 Ohm resistor calibration */
>> if (phy->index == 0)
>> sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN,
>> 0x01, 1);
>> @@ -867,7 +868,6 @@ static const struct sun4i_usb_phy_cfg
>> sun4i_a10_cfg = {
>> .disc_thresh = 3,
>> .phyctl_offset = REG_PHYCTL_A10,
>> .dedicated_clocks = false,
>> -.enable_pmu_unk1 = false,
>> };
>>
>> static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
>> @@ -876,7 +876,6 @@ static const struct sun4i_usb_phy_cfg
>> sun5i_a13_cfg = {
>> .disc_thresh = 2,
>> .phyctl_offset = REG_PHYCTL_A10,
>> .dedicated_clocks = false,
>> -.enable_pmu_unk1 = false,
>> };
>>
>> static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
>> @@ -885,7 +884,6 @@ static const struct sun4i_usb_phy_cfg
>> sun6i_a31_cfg = {
>> .disc_thresh = 3,
>> .phyctl_offset = REG_PHYCTL_A10,
>> .dedicated_clocks = true,
>> -.enable_pmu_unk1 = false,
>> };
>>
>> static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
>> @@ -894,7 +892,6 @@ static const struct sun4i_usb_phy_cfg
>> sun7i_a20_cfg = {
>> .disc_thresh = 2,
>> .phyctl_offset = REG_PHYCTL_A10,
>> .dedicated_clocks = false,
>> -.enable_pmu_unk1 = false,
>> };
>>
>> static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
>> @@ -903,7 +900,6 @@ static const struct sun4i_usb_phy_cfg
>> sun8i_a23_cfg = {
>> .disc_thresh = 3,
>> .phyctl_offset = REG_PHYCTL_A10,
>> .dedicated_clocks = true,
>> -.enable_pmu_unk1 = false,
>> };
>>
>> static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
>> @@ -912,7 +908,6 @@ static const struct sun4i_usb_phy_cfg
>> sun8i_a33_cfg = {
>> .disc_thresh = 3,
>> .phyctl_offset = REG_PHYCTL_A33,
>> .dedicated_clocks = true,
>> -.enable_pmu_unk1 = false,
>> };
>>
>> static const struct sun4i_usb_phy_cfg sun8i_a83t_cfg = {
>> @@ -929,7 +924,7 @@ static const struct sun4i_usb_phy_cfg
>> sun8i_h3_cfg = {
>> .disc_thresh = 3,
>> .phyctl_offset = REG_PHYCTL_A33,
>> .dedicated_clocks = true,
>> -.enable_pmu_unk1 = true,
>> +.pmu_unk1_clrbits = BIT(1),
>> .phy0_dual_route = true,
>> };
>>
>> @@ -939,7 +934,7 @@ static const struct sun4i_usb_phy_cfg
>> sun8i_r40_cfg = {
>> .disc_thresh = 3,
>> .phyctl_offset = REG_PHYCTL_A33,
>> .dedicated_clocks = true,
>> -.enable_pmu_unk1 = true,
>> +.pmu_unk1_clrbits = BIT(1),
>> .phy0_dual_route = true,
>> };
>>
>> @@ -949,7 +944,7 @@ static const struct sun4i_usb_phy_cfg
>> sun8i_v3s_cfg = {
>> .disc_thresh = 3,
>> .phyctl_offset = REG_PHYCTL_A33,
>> .dedicated_clocks = true,
>> -
[PATCH v2] driver: aspeed: g6: Fix PWMG0 pinctrl setting
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
---
drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c | 24 ++
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
index b673a44ffa3b..1dfb12a5b2ce 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
@@ -367,49 +367,57 @@ FUNC_GROUP_DECL(RMII4, F24, E23, E24, E25, C25, C24, B26,
B25, B24);
#define D22 40
SIG_EXPR_LIST_DECL_SESG(D22, SD1CLK, SD1, SIG_DESC_SET(SCU414, 8));
-SIG_EXPR_LIST_DECL_SEMG(D22, PWM8, PWM8G0, PWM8, SIG_DESC_SET(SCU414, 8));
+SIG_EXPR_LIST_DECL_SEMG(D22, PWM8, PWM8G0, PWM8, SIG_DESC_SET(SCU4B4, 8),
+ SIG_DESC_CLEAR(SCU414, 8));
PIN_DECL_2(D22, GPIOF0, SD1CLK, PWM8);
GROUP_DECL(PWM8G0, D22);
#define E22 41
SIG_EXPR_LIST_DECL_SESG(E22, SD1CMD, SD1, SIG_DESC_SET(SCU414, 9));
-SIG_EXPR_LIST_DECL_SEMG(E22, PWM9, PWM9G0, PWM9, SIG_DESC_SET(SCU4B4, 9));
+SIG_EXPR_LIST_DECL_SEMG(E22, PWM9, PWM9G0, PWM9, SIG_DESC_SET(SCU4B4, 9),
+ SIG_DESC_CLEAR(SCU414, 9));
PIN_DECL_2(E22, GPIOF1, SD1CMD, PWM9);
GROUP_DECL(PWM9G0, E22);
#define D23 42
SIG_EXPR_LIST_DECL_SESG(D23, SD1DAT0, SD1, SIG_DESC_SET(SCU414, 10));
-SIG_EXPR_LIST_DECL_SEMG(D23, PWM10, PWM10G0, PWM10, SIG_DESC_SET(SCU4B4, 10));
+SIG_EXPR_LIST_DECL_SEMG(D23, PWM10, PWM10G0, PWM10, SIG_DESC_SET(SCU4B4, 10),
+ SIG_DESC_CLEAR(SCU414, 10));
PIN_DECL_2(D23, GPIOF2, SD1DAT0, PWM10);
GROUP_DECL(PWM10G0, D23);
#define C23 43
SIG_EXPR_LIST_DECL_SESG(C23, SD1DAT1, SD1, SIG_DESC_SET(SCU414, 11));
-SIG_EXPR_LIST_DECL_SEMG(C23, PWM11, PWM11G0, PWM11, SIG_DESC_SET(SCU4B4, 11));
+SIG_EXPR_LIST_DECL_SEMG(C23, PWM11, PWM11G0, PWM11, SIG_DESC_SET(SCU4B4, 11),
+ SIG_DESC_CLEAR(SCU414, 11));
PIN_DECL_2(C23, GPIOF3, SD1DAT1, PWM11);
GROUP_DECL(PWM11G0, C23);
#define C22 44
SIG_EXPR_LIST_DECL_SESG(C22, SD1DAT2, SD1, SIG_DESC_SET(SCU414, 12));
-SIG_EXPR_LIST_DECL_SEMG(C22, PWM12, PWM12G0, PWM12, SIG_DESC_SET(SCU4B4, 12));
+SIG_EXPR_LIST_DECL_SEMG(C22, PWM12, PWM12G0, PWM12, SIG_DESC_SET(SCU4B4, 12),
+ SIG_DESC_CLEAR(SCU414, 12));
PIN_DECL_2(C22, GPIOF4, SD1DAT2, PWM12);
GROUP_DECL(PWM12G0, C22);
#define A25 45
SIG_EXPR_LIST_DECL_SESG(A25, SD1DAT3, SD1, SIG_DESC_SET(SCU414, 13));
-SIG_EXPR_LIST_DECL_SEMG(A25, PWM13, PWM13G0, PWM13, SIG_DESC_SET(SCU4B4, 13));
+SIG_EXPR_LIST_DECL_SEMG(A25, PWM13, PWM13G0, PWM13, SIG_DESC_SET(SCU4B4, 13),
+ SIG_DESC_CLEAR(SCU414, 13));
PIN_DECL_2(A25, GPIOF5, SD1DAT3, PWM13);
GROUP_DECL(PWM13G0, A25);
#define A24 46
SIG_EXPR_LIST_DECL_SESG(A24, SD1CD, SD1, SIG_DESC_SET(SCU414, 14));
-SIG_EXPR_LIST_DECL_SEMG(A24, PWM14, PWM14G0, PWM14, SIG_DESC_SET(SCU4B4, 14));
+SIG_EXPR_LIST_DECL_SEMG(A24, PWM14, PWM14G0, PWM14, SIG_DESC_SET(SCU4B4, 14),
+ SIG_DESC_CLEAR(SCU414, 14));
PIN_DECL_2(A24, GPIOF6, SD1CD, PWM14);
GROUP_DECL(PWM14G0, A24);
#define A23 47
SIG_EXPR_LIST_DECL_SESG(A23, SD1WP, SD1, SIG_DESC_SET(SCU414, 15));
-SIG_EXPR_LIST_DECL_SEMG(A23, PWM15, PWM15G0, PWM15, SIG_DESC_SET(SCU4B4, 15));
+SIG_EXPR_LIST_DECL_SEMG(A23, PWM15, PWM15G0, PWM15, SIG_DESC_SET(SCU4B4, 15),
+ SIG_DESC_CLEAR(SCU414, 15));
PIN_DECL_2(A23, GPIOF7, SD1WP, PWM15);
GROUP_DECL(PWM15G0, A23);
--
2.17.1
Re: [PATCH v2 00/21] arm64: sunxi: Initial Allwinner H616 SoC support
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 thanks for that!) this version adds some patches to support >> some >> slightly changed devices, like the second EMAC and the AXP not having >> an interrupt. >> Also I added quite some DT binding doc patches. >> USB still does not work, but I include the patches anyway, hoping >> that >> someone can help spotting the issue. >> For a more detailed changelog see below. >> >> Thanks! >> Andre >> >> == >> This series gathers patches to support the Allwinner H616 SoC. This >> is >> a rather uninspired SoC (Quad-A53 with the usual peripherals), but >> allows for some cheap development boards and TV boxes, and supports >> up to 4GB of DRAM. >> >> Various DT binding patches are sprinkled throughout the series, to >> add >> the new compatible names right before they are used. >> Patch 1/21 is the usual drive-by fix, discovered while staring at >> the H6 clock code. >> Patch 3 and 4 add pinctrl support, with the "-R" controller now being >> crippled down to two I2C pins only. If we grow tired of repeating >> this >> exercise for every new SoC variant, I am happy to revive my more >> versatile sunxi pinctrl driver effort from a few years back [1]. >> Patch 6 and 7 add clock support. For the -R clock this is shared with >> the H6 code, as the clocks are identical, with the H616 just having >> fewer of them. The main clocks are different enough to warrant a >> separate >> file. >> Patch 08/21 is pulling a patch from Yangtao's A100 series, since we >> need >> the same fix for MMC support. This will probably be merged >> separately, >> I just include this here to provide a bootable solution. >> Patch 10 teaches the AXP MFD driver to get along without having an >> interrupt, as the H616 apparently does not have an NMI controller >> anymore. >> Patch 12 and 13 add some tweaks to the syscon and EMAC driver, to >> deal >> with the second EMAC clock used for the second Ethernet controller. >> Patches 14 and 15 *try* to add USB support. The same approach works >> with >> the very similar U-Boot PHY driver, but for some reason still fail in >> Linux. Maybe someone spots the issue and can help fixing it? > > There's a judge currently checks for phy type A83T/H6. You may need to > add H616 there. You mean for setting PHY_CTL_VBUSVLDEXT and clearing PHY_CTL_SIDDQ? This is guarded by .type == sun50i_h6_phy, which I also use for the H616. So this should be covered. > Or should we have a bool in the data struct to mark it? I think all > chips that need that is 28nm. Yeah, the usage of .type seems somewhat arbitrary, at the end of the day it's just another quirk for a group of SoCs. Thanks! Andre > >> >> The remaining patches add DT bindings, which just add the new >> compatible >> string along with an existing name as a fallback string. >> Eventually we get the .dtsi for the SoC in patch 19, and the .dts for >> the OrangePi Zero2 board[2] in the last patch. >> >> We have U-Boot and Trusted-Firmware support in a working state, >> booting >> via FEL and even TFTPing kernels work already [3][4]. >> >> Many thanks to Jernej for his tremendous help on this, also for the >> awesome input and help from the #linux-sunxi Freenode channel. >> >> The whole series can also be found here: >> https://github.com/apritzel/linux/commits/h616-v2 >> >> Happy reviewing! >> >> Cheers, >> Andre >> >> [1] >> https://patchwork.ozlabs.org/project/linux-gpio/cover/20171113012523.2328-1-andre.przyw...@arm.com/ >> [2] https://linux-sunxi.org/Xunlong_Orange_Pi_Zero2 >> [3] https://github.com/jernejsk/u-boot/commits/h616-v1 >> [4] https://github.com/apritzel/arm-trusted-firmware/commits/h616-WIP >> >> Changelog v1 .. v2: >> - pinctrl: adjust irq bank map to cover undocumented GPIO bank IRQs >> - use differing h_i2s0 pin output names >> - r-ccu: fix number of used clocks >> - ccu: remove PLL-PERIPHy(4X) >> - ccu: fix gpu1 divider range >> - ccu: fix usb-phy3 parent >> - ccu: add missing TV clocks >> - ccu: rework to CLK_OF_DECLARE style >> - ccu: enable output bit for PLL clocks >> - ccu: renumber clocks >> - .dtsi: drop sun50i-a64-system-control fallback >> - .dtsi: drop unknown SRAM regions >> - .dtsi: add more (undocumented) GPIO interrupts >> - .dtsi: fix I2C3 pin names >> - .dtsi: use a100-emmc fallback for MMC2 >> - .dtsi: add second EMAC controller >> - .dtsi: use H3 MUSB controller fallback >> - .dtsi: fix frame size for USB PHY PMU registers >> - .dtsi: add USB0 PHY references >> - .dtsi: fix IR controller clock source >> - .dts: fix LED naming and swap pins >> - .dts: use 5V supply parent for USB supply >> - .dts: drop dummy IRQ for AXP >> - .dts: enable 3V3 header pin power rail >> - .dts: add SPI flash node >> - .dts: make USB-C port
Re: [PATCH v5 0/5] Unify NUMA implementation between ARM64 & RISC-V
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 > modified to reuse the common implementation to avoid duplication. > > [1] https://lkml.org/lkml/2020/1/10/233 > > This series has been tested on qemu with numa enabled for both RISC-V & ARM64. > It would be great if somebody can test it on numa capable ARM64 hardware > platforms. > This patch series doesn't modify the maintainers list for the common code > (arch_numa) > as I am not sure if somebody from ARM64 community or Greg should take up the > maintainership. Ganapatrao was the original author of the arm64 version. > I would be happy to update that in the next revision once it is decided. > > # numactl --hardware > available: 2 nodes (0-1) > node 0 cpus: 0 1 2 3 > node 0 size: 486 MB > node 0 free: 470 MB > node 1 cpus: 4 5 6 7 > node 1 size: 424 MB > node 1 free: 408 MB > node distances: > node 0 1 > 0: 10 20 > 1: 20 10 > # numactl -show > policy: default > preferred node: current > physcpubind: 0 1 2 3 4 5 6 7 > cpubind: 0 1 > nodebind: 0 1 > membind: 0 1 > > The patches are also available at > https://github.com/atishp04/linux/tree/5.11_numa_unified_v5 > > For RISC-V, the following qemu series is a pre-requisite(already available in > upstream) > https://patchwork.kernel.org/project/qemu-devel/list/?series=303313 > > Testing: > RISC-V: > Tested in Qemu and 2 socket OmniXtend FPGA. > > ARM64: > 2 socket kunpeng920 (4 nodes around 250G a node) > Tested-by: Jonathan Cameron > > Changes from v4->v5: > 1. Added by Acked-by & Reviewed-by tags. > 2. Swapped patch 1 & 2 in v4 version. > > Changes from v3->v4: > 1. Removed redundant duplicate header. > 2. Added Reviewed-by tags. > > Changes from v2->v3: > 1. Added Acked-by/Reviewed-by tags. > 2. Replaced asm/acpi.h with linux/acpi.h > 3. Defined arch_acpi_numa_init as static. > > Changes from v1->v2: > 1. Replaced ARM64 specific compile time protection with ACPI specific ones. > 2. Dropped common pcibus_to_node changes. Added required changes in RISC-V. > 3. Fixed few typos. > > Atish Patra (4): > arm64, numa: Change the numa init functions name to be generic > numa: Move numa implementation to common code > riscv: Separate memory init from paging init > riscv: Add numa support for riscv64 platform > > Greentime Hu (1): > riscv: Add support pte_protnone and pmd_protnone if > CONFIG_NUMA_BALANCING > > arch/arm64/Kconfig| 1 + > arch/arm64/include/asm/numa.h | 48 + > arch/arm64/kernel/acpi_numa.c | 12 - > arch/arm64/mm/Makefile| 1 - > arch/arm64/mm/init.c | 4 +- > arch/riscv/Kconfig| 31 ++- > arch/riscv/include/asm/mmzone.h | 13 + > arch/riscv/include/asm/numa.h | 8 +++ > arch/riscv/include/asm/pci.h | 14 + > arch/riscv/include/asm/pgtable.h | 21 > arch/riscv/kernel/setup.c | 11 +++- > arch/riscv/kernel/smpboot.c | 12 - > arch/riscv/mm/init.c | 10 +++- > drivers/base/Kconfig | 6 +++ > drivers/base/Makefile | 1 + > .../mm/numa.c => drivers/base/arch_numa.c | 27 -- > include/asm-generic/numa.h| 52 +++ > 17 files changed, 200 insertions(+), 72 deletions(-) > create mode 100644 arch/riscv/include/asm/mmzone.h > create mode 100644 arch/riscv/include/asm/numa.h > rename arch/arm64/mm/numa.c => drivers/base/arch_numa.c (96%) > create mode 100644 include/asm-generic/numa.h > > -- > 2.25.1 > > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv Hey Palmer, I did not see this series in for-next. Let me know if you need anything else to be done for this series. -- Regards, Atish
Re: [PATCH v3 1/2] dt-bindings: hwlock: add sun8i_hwspinlock documentation
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 driver for sun8i
compatible SoCs.
Signed-off-by: Wilken Gottwalt
---
.../bindings/hwlock/sun8i-hwspinlock.yaml | 63 +++
1 file changed, 63 insertions(+)
create mode 100644
Documentation/devicetree/bindings/hwlock/sun8i-hwspinlock.yaml
diff --git a/Documentation/devicetree/bindings/hwlock/sun8i-hwspinlock.yaml
b/Documentation/devicetree/bindings/hwlock/sun8i-hwspinlock.yaml new file
mode 100644
index ..2954ee0b36a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/sun8i-hwspinlock.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwlock/sun8i-hwspinlock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SUN8I hardware spinlock driver for Allwinner sun8i compatible SoCs
+
+maintainers:
+ - Wilken Gottwalt
+
+properties:
+ compatible:
+enum:
+ - allwinner,sun8i-hwspinlock
>>>
>>> This can be a const instead of an enum, and since it was introduced with
>>> the A33 it should be sun8i-a33-hwspinlock. There's a lot of SoCs in that
>>> family, some without that IP, and we could even see new SoCs in that
>>> family with a different IP at some point.
>>
>> I just looked at the A31 ARISC blob, and it uses the hwspinlock hardware
>> as well, with the same MMIO address and gate/reset bits as A33-H3. So
>> the first compatible would actually be sun6i-a31-hwspinlock.
>
> Hmm, so it would make sense to also change the drivers symbols from sun8i to
> sun6i, right?
Correct.
> Before I do that, is there maybe a sun4i which also includes
> the hwspinlock unit? Just in case :D
There is a sun4i, but there is no evidence it contains the hwspinlock unit.
Cheers,
Samuel
>
> greetings,
> Wilken
>
>> Cheers,
>> Samuel
>>
+
+reg: # 0x01C18000 (H2+, H3, H5), 0x03004000 (H6), length
0x1000
+ maxItems: 1
>>>
>>> There's no need for those comments
>>>
+
+clocks: # phandle to the reference clock
>>>
>>> This should be the description, and it's fairly obvious so you don't
>>> really need that comment.
>>>
+ maxItems: 1
+
+clock-names: # name of the bus ("ahb")
+ maxItems: 1
>>>
>>> You don't need clock-names if there's a single clock
>>>
+
+resets: # phandle to the reset control
+ maxItems: 1
>>>
>>> Same thing than for the clocks
>>>
+
+reset-names: # name of the bus ("ahb")
+ maxItems: 1
+
>>>
>>> Ditto
>>>
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+additionalProperties: false
+
+examples:
+
+ - |
+/* H2+ based OrangePi Zero */
+hwspinlock: hwspinlock@1C18000 {
>>>
>>> Unit-address's are lowercase
>>>
+ compatible = "allwinner,sun8i-hwspinlock";
+ reg = <0x01c18000 0x1000>;
+ clocks = < CLK_BUS_SPINLOCK>;
+ clock-names = "ahb";
+ resets = < RST_BUS_SPINLOCK>;
+ reset-names = "ahb";
+};
+
+/* H6 based OrangePi 3 */
+hwspinlock: hwspinlock@3004000 {
+ compatible = "allwinner,sun8i-hwspinlock";
+ reg = <0x03004000 0x1000>;
+ clocks = < CLK_BUS_SPINLOCK>;
+ clock-names = "ahb";
+ resets = < RST_BUS_SPINLOCK>;
+ reset-names = "ahb";
+};
>>>
>>> Different examples should be different items on that list, but both are
>>> essentially the same binding so you can drop one.
>>>
>>> Maxime
>>>
>>
>
