Re: [PATCH v9 00/21] Generic page walk and ptdump
On 07/25/2019 03:00 PM, Will Deacon wrote:
> On Thu, Jul 25, 2019 at 02:39:22PM +0530, Anshuman Khandual wrote:
>> On 07/24/2019 07:05 PM, Steven Price wrote:
>>> There isn't any problem as such with using p?d_large macros. However the
>>> name "large" has caused confusion in the past. In particular there are
>>> two types of "large" page:
>>>
>>> 1. leaf entries at high levels than normal ('sections' on Arm, for 4K
>>> pages this gives you 2MB and 1GB pages).
>>>
>>> 2. sets of contiguous entries that can share a TLB entry (the
>>> 'Contiguous bit' on Arm - which for 4K pages gives you 16 entries = 64
>>> KB 'pages').
>>
>> This is arm64 specific and AFAIK there are no other architectures where there
>> will be any confusion wrt p?d_large() not meaning a single entry.
>>
>> As you have noted before if we are printing individual entries with PTE_CONT
>> then they need not be identified as p??d_large(). In which case p?d_large()
>> can just safely point to p?d_sect() identifying regular huge leaf entries.
>
> Steven's stuck in the middle of things here, but I do object to p?d_large()
> because I find it bonkers to have p?d_large() and p?d_huge() mean completely
> different things when they are synonyms in the English language.
Agreed that both p?d_large() and p?d_huge() should not exist at the same time
when they imply the same thing. I believe all these name proliferation happened
because THP, HugeTLB and kernel large mappings like linear, vmemmap, ioremap etc
which the platform code had to deal with in various forms.
>
> Yes, p?d_leaf() matches the terminology used by the Arm architecture, but
> given that most page table structures are arranged as a 'tree', then it's
> not completely unreasonable, in my opinion. If you have a more descriptive
> name, we could use that instead. We could also paint it blue.
The alternate name chosen p?d_leaf() is absolutely fine and it describes the
entry as intended. There is no disagreement over that. My original concern
was introduction of yet another page table helper.
>
>>> In many cases both give the same effect (reduce pressure on TLBs and
>>> requires contiguous and aligned physical addresses). But for this case
>>> we only care about the 'leaf' case (because the contiguous bit makes no
>>> difference to walking the page tables).
>>
>> Right and we can just safely identify section entries with it. What will be
>> the problem with that ? Again this is only arm64 specific.
>>
>>>
>>> As far as I'm aware p?d_large() currently implements the first and
>>> p?d_(trans_)huge() implements either 1 or 2 depending on the architecture.
>>
>> AFAIK option 2 exists only on arm6 platform. IIUC generic MM requires two
>> different huge page dentition from platform. HugeTLB identifies large entries
>> at PGD|PUD|PMD after converting it's content into PTE first. So there is no
>> need for direct large page definitions for other levels.
>>
>> 1. THP - pmd_trans_huge()
>> 2. HugeTLB - pte_huge() CONFIG_ARCH_WANT_GENERAL_HUGETLB is set
>>
>> A simple check for p?d_large() on mm/ and include/linux shows that there are
>> no existing usage for these in generic MM. Hence it is available.
>
> Alternatively, it means we have a good opportunity to give it a better name
> before it spreads into the core code.
Fair enough, that is another way. So you expect existing platform definitions
for p?d_large()/p?d_huge() getting cleaned up and to start using new p?d_leaf()
instead ?
>
>> IMHO the new addition of p?d_leaf() can be avoided and p?d_large() should be
>> cleaned up (if required) in platforms and used in generic functions.
>
> Again, I disagree and think p?d_large() should be confined to arch code
> if it sticks around at all.
All of those instances should migrate to using p?d_leaf() eventually else
there will be three different helpers which probably mean the same thing.
Re: linux-next: Fixes tag needs some work in the sound-asoc tree
Stephen,
On 26/07/2019 0.27, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> 9fcf9139a2fd ("ASoC: ti: davinci-mcasp: Fix clk PDIR handling for i2s
> master mode")
>
> Fixes tag
>
> Fixes: 2302be4126f52 ("ASoC: davinci-mcasp: Update PDIR (pin direction)
> register handling")
>
> has these problem(s):
>
> - Target SHA1 does not exist
>
> Did you mean
>
> Fixes: ca3d9433349e ("ASoC: davinci-mcasp: Update PDIR (pin direction)
> register handling")
Indeed this is the correct SHA1, looks like the 2302be4126f52 is on TI's
4.19-LTS branch and it got into the commit message because I have
validated first on that before moving on to linux-next.
Mark: can you either drop the patch and I'll send a new one with fixed
SHA1 or can you fix the commit message in place?
Sorry.
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v8 2/4] uprobe: use original page when all uprobes are removed
Hi Oleg, >> >> No. Yes, deny_write_access() protects mm->exe_file, but not the dynamic >> libraries or other files which can be mmaped. > > I see. Let me see how we can cover this. > >> and I am worried this code can try to lock the same page twice... Say, the probed application does MADV_DONTNEED and then writes "int3" into vma->vm_file at the same address to fool verify_opcode(). >>> >>> Do you mean the case where old_page == new_page? >> >> Yes, >> >>> I think this won't >>> happen, because in uprobe_write_opcode() we only do orig_page for >>> !is_register case. >> >> See above. >> >> !is_register doesn't necessarily mean the original page was previously >> cow'ed. >> And even if it was cow'ed, MADV_DONTNEED can restore the original mapping. > > I guess I know the case now. We can probably avoid this with an simple > check for old_page == new_page? I decided to follow your suggestion of "unmap old_page; fault in orig_page". Please see v9 of the set. Thanks, Song
[PATCH] KVM: X86: Use IPI shorthands in kvm guest when support
From: Wanpeng Li
IPI shorthand is supported now by linux apic/x2apic driver, switch to
IPI shorthand for all excluding self and all including self destination
shorthand in kvm guest, to avoid splitting the target mask into serveral
PV IPI hypercalls.
Cc: Thomas Gleixner
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Sean Christopherson
Cc: Nadav Amit
Signed-off-by: Wanpeng Li
---
Note: rebase against tip tree's x86/apic branch
arch/x86/kernel/kvm.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index b7f34fe..87b73b8 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -34,7 +34,9 @@
#include
#include
+static struct apic orig_apic;
static int kvmapf = 1;
+DECLARE_STATIC_KEY_FALSE(apic_use_ipi_shorthand);
static int __init parse_no_kvmapf(char *arg)
{
@@ -507,12 +509,18 @@ static void kvm_send_ipi_mask_allbutself(const struct
cpumask *mask, int vector)
static void kvm_send_ipi_allbutself(int vector)
{
- kvm_send_ipi_mask_allbutself(cpu_online_mask, vector);
+ if (static_branch_likely(_use_ipi_shorthand))
+ orig_apic.send_IPI_allbutself(vector);
+ else
+ kvm_send_ipi_mask_allbutself(cpu_online_mask, vector);
}
static void kvm_send_ipi_all(int vector)
{
- __send_ipi_mask(cpu_online_mask, vector);
+ if (static_branch_likely(_use_ipi_shorthand))
+ orig_apic.send_IPI_allbutself(vector);
+ else
+ __send_ipi_mask(cpu_online_mask, vector);
}
/*
@@ -520,6 +528,8 @@ static void kvm_send_ipi_all(int vector)
*/
static void kvm_setup_pv_ipi(void)
{
+ orig_apic = *apic;
+
apic->send_IPI_mask = kvm_send_ipi_mask;
apic->send_IPI_mask_allbutself = kvm_send_ipi_mask_allbutself;
apic->send_IPI_allbutself = kvm_send_ipi_allbutself;
--
2.7.4
[PATCH RESEND 1/2] KVM: LAPIC: Add pv ipi tracepoint
From: Wanpeng Li
Add pv ipi tracepoint.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/lapic.c | 2 ++
arch/x86/kvm/trace.h | 25 +
2 files changed, 27 insertions(+)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 42da7eb..403ae3f 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -562,6 +562,8 @@ int kvm_pv_send_ipi(struct kvm *kvm, unsigned long
ipi_bitmap_low,
irq.level = (icr & APIC_INT_ASSERT) != 0;
irq.trig_mode = icr & APIC_INT_LEVELTRIG;
+ trace_kvm_pv_send_ipi(irq.vector, min, ipi_bitmap_low, ipi_bitmap_high);
+
if (icr & APIC_DEST_MASK)
return -KVM_EINVAL;
if (icr & APIC_SHORT_MASK)
diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
index b5c831e..ce6ee34 100644
--- a/arch/x86/kvm/trace.h
+++ b/arch/x86/kvm/trace.h
@@ -1462,6 +1462,31 @@ TRACE_EVENT(kvm_hv_send_ipi_ex,
__entry->vector, __entry->format,
__entry->valid_bank_mask)
);
+
+/*
+ * Tracepoints for kvm_pv_send_ipi.
+ */
+TRACE_EVENT(kvm_pv_send_ipi,
+ TP_PROTO(u32 vector, u32 min, unsigned long ipi_bitmap_low, unsigned
long ipi_bitmap_high),
+ TP_ARGS(vector, min, ipi_bitmap_low, ipi_bitmap_high),
+
+ TP_STRUCT__entry(
+ __field(u32, vector)
+ __field(u32, min)
+ __field(unsigned long, ipi_bitmap_low)
+ __field(unsigned long, ipi_bitmap_high)
+ ),
+
+ TP_fast_assign(
+ __entry->vector = vector;
+ __entry->min = min;
+ __entry->ipi_bitmap_low = ipi_bitmap_low;
+ __entry->ipi_bitmap_high = ipi_bitmap_high;
+ ),
+
+ TP_printk("vector %d min 0x%x ipi_bitmap_low 0x%lx ipi_bitmap_high
0x%lx",
+ __entry->vector, __entry->min, __entry->ipi_bitmap_low,
__entry->ipi_bitmap_high)
+);
#endif /* _TRACE_KVM_H */
#undef TRACE_INCLUDE_PATH
--
2.7.4
[PATCH RESEND 2/2] KVM: X86: Add pv tlb shootdown tracepoint
From: Wanpeng Li
Add pv tlb shootdown tracepoint.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/trace.h | 19 +++
arch/x86/kvm/x86.c | 2 ++
2 files changed, 21 insertions(+)
diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
index ce6ee34..84f32d3 100644
--- a/arch/x86/kvm/trace.h
+++ b/arch/x86/kvm/trace.h
@@ -1487,6 +1487,25 @@ TRACE_EVENT(kvm_pv_send_ipi,
TP_printk("vector %d min 0x%x ipi_bitmap_low 0x%lx ipi_bitmap_high
0x%lx",
__entry->vector, __entry->min, __entry->ipi_bitmap_low,
__entry->ipi_bitmap_high)
);
+
+TRACE_EVENT(kvm_pv_tlb_flush,
+ TP_PROTO(unsigned int vcpu_id, bool need_flush_tlb),
+ TP_ARGS(vcpu_id, need_flush_tlb),
+
+ TP_STRUCT__entry(
+ __field(unsigned int, vcpu_id )
+ __field(bool, need_flush_tlb )
+ ),
+
+ TP_fast_assign(
+ __entry->vcpu_id= vcpu_id;
+ __entry->need_flush_tlb = need_flush_tlb;
+ ),
+
+ TP_printk("vcpu %u need_flush_tlb %s", __entry->vcpu_id,
+ __entry->need_flush_tlb ? "true" : "false")
+);
+
#endif /* _TRACE_KVM_H */
#undef TRACE_INCLUDE_PATH
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2c32311..f487c9a 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2458,6 +2458,8 @@ static void record_steal_time(struct kvm_vcpu *vcpu)
* Doing a TLB flush here, on the guest's behalf, can avoid
* expensive IPIs.
*/
+ trace_kvm_pv_tlb_flush(vcpu->vcpu_id,
+ vcpu->arch.st.steal.preempted & KVM_VCPU_FLUSH_TLB);
if (xchg(>arch.st.steal.preempted, 0) & KVM_VCPU_FLUSH_TLB)
kvm_vcpu_flush_tlb(vcpu, false);
--
2.7.4
[PATCH RESEND] KVM: X86: Use IPI shorthands in kvm guest when support
From: Wanpeng Li
IPI shorthand is supported now by linux apic/x2apic driver, switch to
IPI shorthand for all excluding self and all including self destination
shorthand in kvm guest, to avoid splitting the target mask into serveral
PV IPI hypercalls.
Cc: Thomas Gleixner
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Sean Christopherson
Cc: Nadav Amit
Signed-off-by: Wanpeng Li
---
Note: rebase against tip tree's x86/apic branch
arch/x86/kernel/kvm.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index b7f34fe..87b73b8 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -34,7 +34,9 @@
#include
#include
+static struct apic orig_apic;
static int kvmapf = 1;
+DECLARE_STATIC_KEY_FALSE(apic_use_ipi_shorthand);
static int __init parse_no_kvmapf(char *arg)
{
@@ -507,12 +509,18 @@ static void kvm_send_ipi_mask_allbutself(const struct
cpumask *mask, int vector)
static void kvm_send_ipi_allbutself(int vector)
{
- kvm_send_ipi_mask_allbutself(cpu_online_mask, vector);
+ if (static_branch_likely(_use_ipi_shorthand))
+ orig_apic.send_IPI_allbutself(vector);
+ else
+ kvm_send_ipi_mask_allbutself(cpu_online_mask, vector);
}
static void kvm_send_ipi_all(int vector)
{
- __send_ipi_mask(cpu_online_mask, vector);
+ if (static_branch_likely(_use_ipi_shorthand))
+ orig_apic.send_IPI_all(vector);
+ else
+ __send_ipi_mask(cpu_online_mask, vector);
}
/*
@@ -520,6 +528,8 @@ static void kvm_send_ipi_all(int vector)
*/
static void kvm_setup_pv_ipi(void)
{
+ orig_apic = *apic;
+
apic->send_IPI_mask = kvm_send_ipi_mask;
apic->send_IPI_mask_allbutself = kvm_send_ipi_mask_allbutself;
apic->send_IPI_allbutself = kvm_send_ipi_allbutself;
--
2.7.4
Re: [PATCH] KVM: X86: Use IPI shorthands in kvm guest when support
On Fri, 26 Jul 2019 at 14:10, Wanpeng Li wrote:
>
> From: Wanpeng Li
>
> IPI shorthand is supported now by linux apic/x2apic driver, switch to
> IPI shorthand for all excluding self and all including self destination
> shorthand in kvm guest, to avoid splitting the target mask into serveral
> PV IPI hypercalls.
>
> Cc: Thomas Gleixner
> Cc: Paolo Bonzini
> Cc: Radim Krčmář
> Cc: Sean Christopherson
> Cc: Nadav Amit
> Signed-off-by: Wanpeng Li
> ---
> Note: rebase against tip tree's x86/apic branch
>
> arch/x86/kernel/kvm.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index b7f34fe..87b73b8 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -34,7 +34,9 @@
> #include
> #include
>
> +static struct apic orig_apic;
> static int kvmapf = 1;
> +DECLARE_STATIC_KEY_FALSE(apic_use_ipi_shorthand);
>
> static int __init parse_no_kvmapf(char *arg)
> {
> @@ -507,12 +509,18 @@ static void kvm_send_ipi_mask_allbutself(const struct
> cpumask *mask, int vector)
>
> static void kvm_send_ipi_allbutself(int vector)
> {
> - kvm_send_ipi_mask_allbutself(cpu_online_mask, vector);
> + if (static_branch_likely(_use_ipi_shorthand))
> + orig_apic.send_IPI_allbutself(vector);
> + else
> + kvm_send_ipi_mask_allbutself(cpu_online_mask, vector);
> }
>
> static void kvm_send_ipi_all(int vector)
> {
> - __send_ipi_mask(cpu_online_mask, vector);
> + if (static_branch_likely(_use_ipi_shorthand))
> + orig_apic.send_IPI_allbutself(vector);
Make a mistake here, just resend the patch.
> + else
> + __send_ipi_mask(cpu_online_mask, vector);
> }
>
> /*
> @@ -520,6 +528,8 @@ static void kvm_send_ipi_all(int vector)
> */
> static void kvm_setup_pv_ipi(void)
> {
> + orig_apic = *apic;
> +
> apic->send_IPI_mask = kvm_send_ipi_mask;
> apic->send_IPI_mask_allbutself = kvm_send_ipi_mask_allbutself;
> apic->send_IPI_allbutself = kvm_send_ipi_allbutself;
> --
> 2.7.4
>
[PATCH v2 1/2] dt-bindings: vendor-prefixes: Add Admatec AG
Add vendor prefix for Admatec AG. Signed-off-by: Krzysztof Kozlowski --- Changes since v1: New patch --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 6992ffab..94c816f74209 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -43,6 +43,8 @@ patternProperties: description: AD Holdings Plc. "^adi,.*": description: Analog Devices, Inc. + "^admatec,.*": +description: Admatec AG "^advantech,.*": description: Advantech Corporation "^aeroflexgaisler,.*": -- 2.17.1
[PATCH v2 2/2] ARM: dts: imx6ul-kontron-n6310: Add Kontron i.MX6UL N6310 SoM and boards
Add support for i.MX6UL modules from Kontron Electronics GmbH (before
acquisition: Exceet Electronics) and evalkit boards based on it:
1. N6310 SOM: i.MX6 UL System-on-Module, a 25x25 mm solderable module
(LGA pads and pin castellations) with 256 MB RAM, 1 MB NOR-Flash,
256 MB NAND and other interfaces,
2. N6310 S: evalkit, w/wo eMMC, without display,
3. N6310 S 43: evalkit with 4.3" display,
4. N6310 S 50: evalkit with 5.0" display.
This includes device nodes for unsupported displays (Admatec
T043C004800272T2A and T070P133T0S301).
The work is based on Exceet/Kontron source code (GPLv2) with numerous
changes:
1. Reorganize files,
2. Rename Exceet -> Kontron,
3. Rename models/compatibles to match newest Kontron product naming,
4. Fix coding style errors,
5. Fix DTC warnings,
6. Extend compatibles so eval boards inherit the SoM compatible,
7. Use defines instead of GPIO flag values,
8. Use proper vendor compatible for Macronix SPI NOR,
9. Sort nodes alphabetically.
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1, after Frieder's review:
1. Remove unneeded license notes,
2. Add Kontron copyright (2018),
3. Rename the files/models/compatibles to new naming - N6310,
4. Remove unneeded CPU operating points override,
5. Switch regulator nodes into simple children nodes without addresses
(so not simple bus),
6. Use proper vendor compatible for Macronix SPI NOR.
---
.../devicetree/bindings/arm/fsl.yaml | 4 +
arch/arm/boot/dts/Makefile| 3 +
.../boot/dts/imx6ul-kontron-n6310-s-43.dts| 120 +
.../boot/dts/imx6ul-kontron-n6310-s-50.dts| 120 +
arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts | 424 ++
.../boot/dts/imx6ul-kontron-n6310-som.dtsi| 137 ++
6 files changed, 808 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts
create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-s-50.dts
create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts
create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-som.dtsi
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 7294ac36f4c0..afb61a55e26f 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -161,6 +161,10 @@ properties:
items:
- enum:
- fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board
+ - kontron,n6310-som # Kontron N6310 SOM
+ - kontron,n6310-s # Kontron N6310 S Board
+ - kontron,n6310-s-43# Kontron N6310 S 43 Board
+ - kontron,n6310-s-50# Kontron N6310 S 50 Board
- const: fsl,imx6ul
- description: i.MX6ULL based Boards
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9159fa2cea90..28b6cb3454a3 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -569,6 +569,9 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-geam.dtb \
imx6ul-isiot-emmc.dtb \
imx6ul-isiot-nand.dtb \
+ imx6ul-kontron-n6310-s.dtb \
+ imx6ul-kontron-n6310-s-43.dtb \
+ imx6ul-kontron-n6310-s-50.dtb \
imx6ul-liteboard.dtb \
imx6ul-opos6uldev.dtb \
imx6ul-pico-hobbit.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts
b/arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts
new file mode 100644
index ..63a0d8408fea
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts
@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 exceet electronics GmbH
+ * Copyright (C) 2018 Kontron Electronics GmbH
+ * Copyright (c) 2019 Krzysztof Kozlowski
+ */
+
+#include "imx6ul-kontron-n6310-s.dts"
+
+/ {
+ model = "Kontron N6310 S 43";
+ compatible = "kontron,n6310-s-43", "kontron,n6310-s",
+"kontron,n6310-som", "fsl,imx6ul";
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = < 0 500>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+ status = "okay";
+ };
+
+ panel {
+ compatible = "admatec,t043c004800272t2a";
+ backlight = <>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+};
+
+ {
+ gt911@5d {
+ compatible = "goodix,gt928";
+ reg = <0x5d>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_cap_touch>;
+ interrupt-parent = <>;
+ interrupts = <6 8>;
+ reset-gpios = < 8 GPIO_ACTIVE_HIGH>;
+ irq-gpios = < 6 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+ {
+ pinctrl_lcdif_dat: lcdifdatgrp {
+
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On Wed, Jul 24, 2019 at 09:14:51PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.2.3 release. > There are 413 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri 26 Jul 2019 07:13:35 PM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.3-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.2.y > and the diffstat can be found below. > > thanks, > > greg k-h Compiled and booted with no regressions on my system. Cheers, Kelsey
Re: [PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring
David Laight 於 2019年7月25日 週四 下午5:21寫道：
>
> From: Jian-Hong Pan
> > Sent: 25 July 2019 09:09
> > Each skb as the element in RX ring was expected with sized buffer 8216
> > (RTK_PCI_RX_BUF_SIZE) bytes. However, the skb buffer's true size is
> > 16640 bytes for alignment after allocated, x86_64 for example. And, the
> > difference will be enlarged 512 times (RTK_MAX_RX_DESC_NUM).
> > To prevent that much wasted memory, this patch follows David's
> > suggestion [1] and uses general buffer arrays, instead of skbs as the
> > elements in RX ring.
> ...
> > for (i = 0; i < len; i++) {
> > - skb = dev_alloc_skb(buf_sz);
> > - if (!skb) {
> > + buf = devm_kzalloc(rtwdev->dev, buf_sz, GFP_ATOMIC);
>
> You should do this allocation somewhere than can sleep.
> So you don't need GFP_ATOMIC, making the allocate (and dma map)
> much less likely to fail.
> If they do fail using a smaller ring might be better than failing
> completely.
Ok, I can tweak and try it.
> I suspect that buf_sz gets rounded up somewhat.
> Also you almost certainly want 'buf' to be cache-line aligned.
> I don't think devm_kzalloc() guarantees that at all.
Sure
> While allocating all 512 buffers in one block (just over 4MB)
> is probably not a good idea, you may need to allocated (and dma map)
> then in groups.
Thanks for reviewing. But got questions here to double confirm the idea.
According to original code, it allocates 512 skbs for RX ring and dma
mapping one by one. So, the new code allocates memory buffer 512
times to get 512 buffer arrays. Will the 512 buffers arrays be in one
block? Do you mean aggregate the buffers as a scatterlist and use
dma_map_sg?
Thank you,
Jain-Hong Pan
[Regression] Missing device nodes for ETR, ETF and STM after CONFIG_UEVENT_HELPER=n
Hi,
When trying to test my coresight patches, I found that etr,etf and stm
device nodes are missing from /dev.
Bisection gives this as the bad commit.
1be01d4a57142ded23bdb9e0c8d9369e693b26cc is the first bad commit
commit 1be01d4a57142ded23bdb9e0c8d9369e693b26cc
Author: Geert Uytterhoeven
Date: Thu Mar 14 12:13:50 2019 +0100
driver: base: Disable CONFIG_UEVENT_HELPER by default
Since commit 7934779a69f1184f ("Driver-Core: disable /sbin/hotplug by
default"), the help text for the /sbin/hotplug fork-bomb says
"This should not be used today [...] creates a high system load, or
[...] out-of-memory situations during bootup". The rationale for this
was that no recent mainstream system used this anymore (in 2010!).
A few years later, the complete uevent helper support was made optional
in commit 86d56134f1b67d0c ("kobject: Make support for uevent_helper
optional."). However, if was still left enabled by default, to support
ancient userland.
Time passed by, and nothing should use this anymore, so it can be
disabled by default.
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Greg Kroah-Hartman
drivers/base/Kconfig | 1 -
1 file changed, 1 deletion(-)
Any idea on this?
-Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 4.19 000/271] 4.19.61-stable review
On Wed, Jul 24, 2019 at 09:17:49PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.19.61 release. > There are 271 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri 26 Jul 2019 07:13:35 PM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.61-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.19.y > and the diffstat can be found below. > > thanks, > > greg k-h Compiled and booted with no regressions on my system. Cheers, Kelsey
Re: [PATCH 5.1 000/371] 5.1.20-stable review
On Wed, Jul 24, 2019 at 09:15:52PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.1.20 release. > There are 371 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri 26 Jul 2019 07:13:35 PM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.20-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.1.y > and the diffstat can be found below. > > thanks, > > greg k-h Compiled and booted with no regressions on my system. Cheers, Kelsey
[PATCH v2 1/1] platform/x86/pcengines-apuv2: add mpcie reset gpio export
On APUx we have also mpcie2/mpcie3 reset pins. To make it possible to reset
the ports from the userspace, add the definition to this platform
device. The gpio can then be exported by the legancy gpio subsystem to
toggle the mpcie reset pin.
Signed-off-by: Florian Eckert
---
v2:
Noting changed for this patch. Only resend because other patches of
the series where dropped or updated and resend by other people
drivers/platform/x86/pcengines-apuv2.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/platform/x86/pcengines-apuv2.c
b/drivers/platform/x86/pcengines-apuv2.c
index c1ca931e1fab..f6d8ed100cab 100644
--- a/drivers/platform/x86/pcengines-apuv2.c
+++ b/drivers/platform/x86/pcengines-apuv2.c
@@ -32,6 +32,8 @@
#define APU2_GPIO_REG_LED3 AMD_FCH_GPIO_REG_GPIO59_DEVSLP1
#define APU2_GPIO_REG_MODESW AMD_FCH_GPIO_REG_GPIO32_GE1
#define APU2_GPIO_REG_SIMSWAP AMD_FCH_GPIO_REG_GPIO33_GE2
+#define APU2_GPIO_REG_MPCIE2 AMD_FCH_GPIO_REG_GPIO59_DEVSLP0
+#define APU2_GPIO_REG_MPCIE3 AMD_FCH_GPIO_REG_GPIO51
/* order in which the gpio lines are defined in the register list */
#define APU2_GPIO_LINE_LED10
@@ -39,6 +41,8 @@
#define APU2_GPIO_LINE_LED32
#define APU2_GPIO_LINE_MODESW 3
#define APU2_GPIO_LINE_SIMSWAP 4
+#define APU2_GPIO_LINE_MPCIE2 5
+#define APU2_GPIO_LINE_MPCIE3 6
/* gpio device */
@@ -48,6 +52,8 @@ static int apu2_gpio_regs[] = {
[APU2_GPIO_LINE_LED3] = APU2_GPIO_REG_LED3,
[APU2_GPIO_LINE_MODESW] = APU2_GPIO_REG_MODESW,
[APU2_GPIO_LINE_SIMSWAP]= APU2_GPIO_REG_SIMSWAP,
+ [APU2_GPIO_LINE_MPCIE2] = APU2_GPIO_REG_MPCIE2,
+ [APU2_GPIO_LINE_MPCIE3] = APU2_GPIO_REG_MPCIE3,
};
static const char * const apu2_gpio_names[] = {
@@ -56,6 +62,8 @@ static const char * const apu2_gpio_names[] = {
[APU2_GPIO_LINE_LED3] = "front-led3",
[APU2_GPIO_LINE_MODESW] = "front-button",
[APU2_GPIO_LINE_SIMSWAP]= "simswap",
+ [APU2_GPIO_LINE_MPCIE2] = "mpcie2_reset",
+ [APU2_GPIO_LINE_MPCIE3] = "mpcie3_reset",
};
static const struct amd_fch_gpio_pdata board_apu2 = {
--
2.11.0
Re: [Regression] Missing device nodes for ETR, ETF and STM after CONFIG_UEVENT_HELPER=n
On 7/26/2019 11:49 AM, Sai Prakash Ranjan wrote:
Hi,
When trying to test my coresight patches, I found that etr,etf and stm
device nodes are missing from /dev.
Bisection gives this as the bad commit.
1be01d4a57142ded23bdb9e0c8d9369e693b26cc is the first bad commit
commit 1be01d4a57142ded23bdb9e0c8d9369e693b26cc
Author: Geert Uytterhoeven
Date: Thu Mar 14 12:13:50 2019 +0100
driver: base: Disable CONFIG_UEVENT_HELPER by default
Since commit 7934779a69f1184f ("Driver-Core: disable /sbin/hotplug by
default"), the help text for the /sbin/hotplug fork-bomb says
"This should not be used today [...] creates a high system load, or
[...] out-of-memory situations during bootup". The rationale for this
was that no recent mainstream system used this anymore (in 2010!).
A few years later, the complete uevent helper support was made
optional
in commit 86d56134f1b67d0c ("kobject: Make support for uevent_helper
optional."). However, if was still left enabled by default, to
support
ancient userland.
Time passed by, and nothing should use this anymore, so it can be
disabled by default.
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Greg Kroah-Hartman
drivers/base/Kconfig | 1 -
1 file changed, 1 deletion(-)
FYI, I am testing on linux-next.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH V6 17/21] arm64: tegra: Enable wake from deep sleep on RTC alarm.
В Sun, 21 Jul 2019 12:40:56 -0700 Sowjanya Komatineni пишет: > This patch updates device tree for RTC and PMC to allow system wake > from deep sleep on RTC alarm. > > Signed-off-by: Sowjanya Komatineni The dot in the end of the commit's title is unnecessary.
Re: [PATCH 2/2] /proc/kpageflags: do not use uninitialized struct pages
On 2019/07/25 18:03, Michal Hocko wrote: > On Thu 25-07-19 02:31:18, Toshiki Fukasawa wrote: >> A kernel panic was observed during reading /proc/kpageflags for >> first few pfns allocated by pmem namespace: >> >> BUG: unable to handle page fault for address: fffe >> [ 114.495280] #PF: supervisor read access in kernel mode >> [ 114.495738] #PF: error_code(0x) - not-present page >> [ 114.496203] PGD 17120e067 P4D 17120e067 PUD 171210067 PMD 0 >> [ 114.496713] Oops: [#1] SMP PTI >> [ 114.497037] CPU: 9 PID: 1202 Comm: page-types Not tainted 5.3.0-rc1 #1 >> [ 114.497621] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS >> rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014 >> [ 114.498706] RIP: 0010:stable_page_flags+0x27/0x3f0 >> [ 114.499142] Code: 82 66 90 66 66 66 66 90 48 85 ff 0f 84 d1 03 00 00 41 >> 54 55 48 89 fd 53 48 8b 57 08 48 8b 1f 48 8d 42 ff 83 e2 01 48 0f 44 c7 <48> >> 8b 00 f6 c4 02 0f 84 57 03 00 00 45 31 e4 48 8b 55 08 48 89 ef >> [ 114.500788] RSP: 0018:a5e601a0fe60 EFLAGS: 00010202 >> [ 114.501373] RAX: fffe RBX: RCX: >> >> [ 114.502009] RDX: 0001 RSI: 7ffca13a7310 RDI: >> d0748900 >> [ 114.502637] RBP: d0748900 R08: 0001 R09: >> >> [ 114.503270] R10: R11: R12: >> 0024 >> [ 114.503896] R13: 0008 R14: 7ffca13a7310 R15: >> a5e601a0ff08 >> [ 114.504530] FS: 7f0266c7f540() GS:962dbbac() >> knlGS: >> [ 114.505245] CS: 0010 DS: ES: CR0: 80050033 >> [ 114.505754] CR2: fffe CR3: 00023a204000 CR4: >> 06e0 >> [ 114.506401] Call Trace: >> [ 114.506660] kpageflags_read+0xb1/0x130 >> [ 114.507051] proc_reg_read+0x39/0x60 >> [ 114.507387] vfs_read+0x8a/0x140 >> [ 114.507686] ksys_pread64+0x61/0xa0 >> [ 114.508021] do_syscall_64+0x5f/0x1a0 >> [ 114.508372] entry_SYSCALL_64_after_hwframe+0x44/0xa9 >> [ 114.508844] RIP: 0033:0x7f0266ba426b >> >> The reason for the panic is that stable_page_flags() which parses >> the page flags uses uninitialized struct pages reserved by the >> ZONE_DEVICE driver. > > Why pmem hasn't initialized struct pages? We proposed to initialize in previous approach but that wasn't merged. (See https://marc.info/?l=linux-mm=152964792500739=2) > Isn't that a bug that should be addressed rather than paper over it like this? I'm not sure. What do you think, Dan? Best regards, Toshiki Fukasawa
[PATCH] iio: mxc4005: Use device-managed APIs
Use device-managed APIs to simplify the code.
The remove function is redundant now and can
be deleted.
Signed-off-by: Chuhong Yuan
---
drivers/iio/accel/mxc4005.c | 35 +++
1 file changed, 7 insertions(+), 28 deletions(-)
diff --git a/drivers/iio/accel/mxc4005.c b/drivers/iio/accel/mxc4005.c
index 637e6e676061..d8b999023ef2 100644
--- a/drivers/iio/accel/mxc4005.c
+++ b/drivers/iio/accel/mxc4005.c
@@ -424,7 +424,7 @@ static int mxc4005_probe(struct i2c_client *client,
indio_dev->modes = INDIO_DIRECT_MODE;
indio_dev->info = _info;
- ret = iio_triggered_buffer_setup(indio_dev,
+ ret = devm_iio_triggered_buffer_setup(>dev, indio_dev,
iio_pollfunc_store_time,
mxc4005_trigger_handler,
NULL);
@@ -452,7 +452,7 @@ static int mxc4005_probe(struct i2c_client *client,
if (ret) {
dev_err(>dev,
"failed to init threaded irq\n");
- goto err_buffer_cleanup;
+ return ret;
}
data->dready_trig->dev.parent = >dev;
@@ -460,43 +460,23 @@ static int mxc4005_probe(struct i2c_client *client,
iio_trigger_set_drvdata(data->dready_trig, indio_dev);
indio_dev->trig = data->dready_trig;
iio_trigger_get(indio_dev->trig);
- ret = iio_trigger_register(data->dready_trig);
+ ret = devm_iio_trigger_register(>dev,
+ data->dready_trig);
if (ret) {
dev_err(>dev,
"failed to register trigger\n");
- goto err_trigger_unregister;
+ return ret;
}
}
- ret = iio_device_register(indio_dev);
+ ret = devm_iio_device_register(>dev, indio_dev);
if (ret < 0) {
dev_err(>dev,
"unable to register iio device %d\n", ret);
- goto err_buffer_cleanup;
+ return ret;
}
return 0;
-
-err_trigger_unregister:
- iio_trigger_unregister(data->dready_trig);
-err_buffer_cleanup:
- iio_triggered_buffer_cleanup(indio_dev);
-
- return ret;
-}
-
-static int mxc4005_remove(struct i2c_client *client)
-{
- struct iio_dev *indio_dev = i2c_get_clientdata(client);
- struct mxc4005_data *data = iio_priv(indio_dev);
-
- iio_device_unregister(indio_dev);
-
- iio_triggered_buffer_cleanup(indio_dev);
- if (data->dready_trig)
- iio_trigger_unregister(data->dready_trig);
-
- return 0;
}
static const struct acpi_device_id mxc4005_acpi_match[] = {
@@ -517,7 +497,6 @@ static struct i2c_driver mxc4005_driver = {
.acpi_match_table = ACPI_PTR(mxc4005_acpi_match),
},
.probe = mxc4005_probe,
- .remove = mxc4005_remove,
.id_table = mxc4005_id,
};
--
2.20.1
Re: [alsa-devel] [RFC PATCH 01/40] soundwire: add debugfs support
Hi Pierre,
A couple of nitpicks:
On Thu, Jul 25, 2019 at 06:39:53PM -0500, Pierre-Louis Bossart wrote:
> Add base debugfs mechanism for SoundWire bus by creating soundwire
> root and master-N and slave-x hierarchy.
>
> Also add SDW Slave SCP, DP0 and DP-N register debug file.
>
> Registers not implemented will print as "XX"
>
> Credits: this patch is based on an earlier internal contribution by
> Vinod Koul, Sanyog Kale, Shreyas Nc and Hardik Shah. The main change
> is the use of scnprintf to avoid known issues with snprintf.
>
> Signed-off-by: Pierre-Louis Bossart
> ---
> drivers/soundwire/Makefile| 4 +-
> drivers/soundwire/bus.c | 6 ++
> drivers/soundwire/bus.h | 24 ++
> drivers/soundwire/bus_type.c | 3 +
> drivers/soundwire/debugfs.c | 156 ++
> drivers/soundwire/slave.c | 1 +
> include/linux/soundwire/sdw.h | 4 +
> 7 files changed, 197 insertions(+), 1 deletion(-)
> create mode 100644 drivers/soundwire/debugfs.c
[snip]
> diff --git a/drivers/soundwire/bus.h b/drivers/soundwire/bus.h
> index 3048ca153f22..06ac4adb0074 100644
> --- a/drivers/soundwire/bus.h
> +++ b/drivers/soundwire/bus.h
> @@ -18,6 +18,30 @@ static inline int sdw_acpi_find_slaves(struct sdw_bus *bus)
> void sdw_extract_slave_id(struct sdw_bus *bus,
> u64 addr, struct sdw_slave_id *id);
>
> +#ifdef CONFIG_DEBUG_FS
> +struct dentry *sdw_bus_debugfs_init(struct sdw_bus *bus);
> +void sdw_bus_debugfs_exit(struct dentry *d);
> +struct dentry *sdw_slave_debugfs_init(struct sdw_slave *slave);
> +void sdw_slave_debugfs_exit(struct dentry *d);
> +void sdw_debugfs_init(void);
> +void sdw_debugfs_exit(void);
> +#else
> +struct dentry *sdw_bus_debugfs_init(struct sdw_bus *bus)
> +{ return NULL; }
static?
> +
> +void sdw_bus_debugfs_exit(struct dentry *d) {}
> +
> +struct dentry *sdw_slave_debugfs_init(struct sdw_slave *slave)
> +{ return NULL; }
> +
> +void sdw_slave_debugfs_exit(struct dentry *d) {}
> +
> +void sdw_debugfs_init(void) {}
> +
> +void sdw_debugfs_exit(void) {}
Same for all the above. You could also declare them inline, but I really hope
the compiler will be smart enough to do that itself.
> +
> +#endif
> +
> enum {
> SDW_MSG_FLAG_READ = 0,
> SDW_MSG_FLAG_WRITE,
> diff --git a/drivers/soundwire/bus_type.c b/drivers/soundwire/bus_type.c
> index 2655602f0cfb..4a465f55039f 100644
> --- a/drivers/soundwire/bus_type.c
> +++ b/drivers/soundwire/bus_type.c
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include "bus.h"
>
> /**
> * sdw_get_device_id - find the matching SoundWire device id
> @@ -177,11 +178,13 @@ EXPORT_SYMBOL_GPL(sdw_unregister_driver);
>
> static int __init sdw_bus_init(void)
> {
> + sdw_debugfs_init();
> return bus_register(_bus_type);
> }
>
> static void __exit sdw_bus_exit(void)
> {
> + sdw_debugfs_exit();
> bus_unregister(_bus_type);
> }
>
> diff --git a/drivers/soundwire/debugfs.c b/drivers/soundwire/debugfs.c
> new file mode 100644
> index ..8d86e100516e
> --- /dev/null
> +++ b/drivers/soundwire/debugfs.c
> @@ -0,0 +1,156 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> +// Copyright(c) 2017-19 Intel Corporation.
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "bus.h"
> +
> +#ifdef CONFIG_DEBUG_FS
> +struct dentry *sdw_debugfs_root;
> +#endif
> +
> +struct dentry *sdw_bus_debugfs_init(struct sdw_bus *bus)
> +{
> + struct dentry *d;
I would remove the above
> + char name[16];
> +
> + if (!sdw_debugfs_root)
> + return NULL;
> +
> + /* create the debugfs master-N */
> + snprintf(name, sizeof(name), "master-%d", bus->link_id);
> + d = debugfs_create_dir(name, sdw_debugfs_root);
> +
> + return d;
And just do
+ return debugfs_create_dir(name, sdw_debugfs_root);
> +}
> +
> +void sdw_bus_debugfs_exit(struct dentry *d)
> +{
> + debugfs_remove_recursive(d);
> +}
> +
> +#define RD_BUF (3 * PAGE_SIZE)
> +
> +static ssize_t sdw_sprintf(struct sdw_slave *slave,
> +char *buf, size_t pos, unsigned int reg)
> +{
> + int value;
> +
> + value = sdw_read(slave, reg);
I personally would join the two lines above, but that's just a personal
preference.
> +
> + if (value < 0)
> + return scnprintf(buf + pos, RD_BUF - pos, "%3x\tXX\n", reg);
> + else
I think it's advised to not use an else in such cases.
Thanks
Guennadi
> + return scnprintf(buf + pos, RD_BUF - pos,
> + "%3x\t%2x\n", reg, value);
> +}
> +
> +static ssize_t sdw_slave_reg_read(struct file *file, char __user *user_buf,
> + size_t count, loff_t *ppos)
> +{
> + struct sdw_slave *slave = file->private_data;
> + unsigned int reg;
> + char *buf;
> + ssize_t ret;
> + int i, j;
> +
> + buf = kzalloc(RD_BUF, GFP_KERNEL);
> + if (!buf)
Re: [PATCH v2 2/2] mmc: Add support for the ASPEED SD controller
On Fri, 26 Jul 2019, at 15:27, Adrian Hunter wrote:
> On 26/07/19 3:52 AM, Andrew Jeffery wrote:
> > On Thu, 25 Jul 2019, at 22:49, Adrian Hunter wrote:
> >> On 12/07/19 6:32 AM, Andrew Jeffery wrote:
> >>> +static int aspeed_sdhci_probe(struct platform_device *pdev)
> >>> +{
> >>> + struct sdhci_pltfm_host *pltfm_host;
> >>> + struct aspeed_sdhci *dev;
> >>> + struct sdhci_host *host;
> >>> + struct resource *res;
> >>> + int slot;
> >>> + int ret;
> >>> +
> >>> + host = sdhci_pltfm_init(pdev, _sdc_pdata, sizeof(*dev));
> >>> + if (IS_ERR(host))
> >>> + return PTR_ERR(host);
> >>> +
> >>> + pltfm_host = sdhci_priv(host);
> >>> + dev = sdhci_pltfm_priv(pltfm_host);
> >>> + dev->parent = dev_get_drvdata(pdev->dev.parent);
> >>> +
> >>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >>> + slot = aspeed_sdhci_calculate_slot(dev, res);
> >>> + if (slot < 0)
> >>> + return slot;
> >>> + dev_info(>dev, "Configuring for slot %d\n", slot);
> >>> + dev->width_mask = !slot ? ASPEED_SDC_S0MMC8 : ASPEED_SDC_S1MMC8;
> >>
> >> That implies that you only support 2 slots which begs the question why
> >> you don't validate slot.
> >
> > I'm not sure what you mean here, but I'll dig into it.
>
> I just meant, if you only support 2 slots:
>
> if (slot > 1)
> return -EINVAL;
>
Oh, sure.
Re: [alsa-devel] [RFC PATCH 09/40] soundwire: cadence_master: fix usage of CONFIG_UPDATE
On Thu, Jul 25, 2019 at 06:40:01PM -0500, Pierre-Louis Bossart wrote:
> Per the hardware documentation, all changes to MCP_CONFIG,
> MCP_CONTROL, MCP_CMDCTRL and MCP_PHYCTRL need to be validated with a
> self-clearing write to MCP_CONFIG_UPDATE.
>
> For some reason, the existing code only does this write to
> CONFIG_UPDATE when enabling interrupts. Add a helper and do the update
> when the CONFIG is changed.
>
> Signed-off-by: Pierre-Louis Bossart
> ---
> drivers/soundwire/cadence_master.c | 29 +
> 1 file changed, 21 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/soundwire/cadence_master.c
> b/drivers/soundwire/cadence_master.c
> index 9f611a1fff0a..eb46cf651d62 100644
> --- a/drivers/soundwire/cadence_master.c
> +++ b/drivers/soundwire/cadence_master.c
> @@ -224,6 +224,22 @@ static int cdns_clear_bit(struct sdw_cdns *cdns, int
> offset, u32 value)
> return -EAGAIN;
> }
>
> +/*
> + * all changes to the MCP_CONFIG, MCP_CONTROL, MCP_CMDCTRL and MCP_PHYCTRL
> + * need to be confirmed with a write to MCP_CONFIG_UPDATE
> + */
> +static int cdns_update_config(struct sdw_cdns *cdns)
> +{
> + int ret;
> +
> + ret = cdns_clear_bit(cdns, CDNS_MCP_CONFIG_UPDATE,
> + CDNS_MCP_CONFIG_UPDATE_BIT);
> + if (ret < 0)
> + dev_err(cdns->dev, "Config update timedout\n");
> +
> + return ret;
> +}
> +
> /*
> * debugfs
> */
> @@ -758,15 +774,9 @@ static int _cdns_enable_interrupt(struct sdw_cdns *cdns)
> */
> int sdw_cdns_enable_interrupt(struct sdw_cdns *cdns)
> {
> - int ret;
> -
> _cdns_enable_interrupt(cdns);
> - ret = cdns_clear_bit(cdns, CDNS_MCP_CONFIG_UPDATE,
> - CDNS_MCP_CONFIG_UPDATE_BIT);
> - if (ret < 0)
> - dev_err(cdns->dev, "Config update timedout\n");
>
> - return ret;
> + return 0;
> }
> EXPORT_SYMBOL(sdw_cdns_enable_interrupt);
>
> @@ -943,7 +953,10 @@ int sdw_cdns_init(struct sdw_cdns *cdns)
>
> cdns_writel(cdns, CDNS_MCP_CONFIG, val);
>
> - return 0;
> + /* commit changes */
> + ret = cdns_update_config(cdns);
> +
> + return ret;
+ return cdns_update_config(cdns);
Thanks
Guennadi
> }
> EXPORT_SYMBOL(sdw_cdns_init);
>
> --
> 2.20.1
>
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Re: [PATCH] cpufreq: schedutil: Don't skip freq update when limits change
On 25-07-19, 08:20, Doug Smythies wrote:
> I tried the patch ("patch2"). It did not fix the issue.
>
> To summarize, all kernel 5.2 based, all intel_cpufreq driver and schedutil
> governor:
>
> Test: Does a busy system respond to maximum CPU clock frequency reduction?
>
> stock, unaltered: No.
> revert ecd2884291261e3fddbc7651ee11a20d596bb514: Yes
> viresh patch: No.
> fast_switch edit: No.
> viresh patch2: No.
Hmm, so I tried to reproduce your setup on my ARM board.
- booted only with CPU0 so I hit the sugov_update_single() routine
- And applied below diff to make CPU look permanently busy:
-8<-
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 2f382b0959e5..afb47490e5dc 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -121,6 +121,7 @@ static void sugov_fast_switch(struct sugov_policy
*sg_policy, u64 time,
if (!sugov_update_next_freq(sg_policy, time, next_freq))
return;
+ pr_info("%s: %d: %u\n", __func__, __LINE__, freq);
next_freq = cpufreq_driver_fast_switch(policy, next_freq);
if (!next_freq)
return;
@@ -424,14 +425,10 @@ static unsigned long sugov_iowait_apply(struct sugov_cpu
*sg_cpu, u64 time,
#ifdef CONFIG_NO_HZ_COMMON
static bool sugov_cpu_is_busy(struct sugov_cpu *sg_cpu)
{
- unsigned long idle_calls = tick_nohz_get_idle_calls_cpu(sg_cpu->cpu);
- bool ret = idle_calls == sg_cpu->saved_idle_calls;
-
- sg_cpu->saved_idle_calls = idle_calls;
- return ret;
+ return true;
}
#else
-static inline bool sugov_cpu_is_busy(struct sugov_cpu *sg_cpu) { return false;
}
+static inline bool sugov_cpu_is_busy(struct sugov_cpu *sg_cpu) { return true; }
#endif /* CONFIG_NO_HZ_COMMON */
/*
@@ -565,6 +562,7 @@ static void sugov_work(struct kthread_work *work)
sg_policy->work_in_progress = false;
raw_spin_unlock_irqrestore(_policy->update_lock, flags);
+ pr_info("%s: %d: %u\n", __func__, __LINE__, freq);
mutex_lock(_policy->work_lock);
__cpufreq_driver_target(sg_policy->policy, freq, CPUFREQ_RELATION_L);
mutex_unlock(_policy->work_lock);
-8<-
Now, the frequency never gets down and so gets set to the maximum
possible after a bit.
- Then I did:
echo >
/sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
Without my patch applied:
The print never gets printed and so frequency doesn't go down.
With my patch applied:
The print gets printed immediately from sugov_work() and so
the frequency reduces.
Can you try with this diff along with my Patch2 ? I suspect there may
be something wrong with the intel_cpufreq driver as the patch fixes
the only path we have in the schedutil governor which takes busyness
of a CPU into account.
--
viresh
Re: [PATCH 1/9] lib/sort.c: implement sort() variant taking context argument
On 26/07/2019 02.05, Andrew Morton wrote:
> On Wed, 19 Jun 2019 14:15:32 +0200 Boris Brezillon
> wrote:
>
>> From: Rasmus Villemoes
>>
>> Our list_sort() utility has always supported a context argument that
>> is passed through to the comparison routine. Now there's a use case
>> for the similar thing for sort().
>>
>> This implements sort_r by simply extending the existing sort function
>> in the obvious way. To avoid code duplication, we want to implement
>> sort() in terms of sort_r(). The naive way to do that is
>>
>> static int cmp_wrapper(const void *a, const void *b, const void *ctx)
>> {
>> int (*real_cmp)(const void*, const void*) = ctx;
>> return real_cmp(a, b);
>> }
>>
>> sort(..., cmp) { sort_r(..., cmp_wrapper, cmp) }
>>
>> but this would do two indirect calls for each comparison. Instead, do
>> as is done for the default swap functions - that only adds a cost of a
>> single easily predicted branch to each comparison call.
>>
>> Aside from introducing support for the context argument, this also
>> serves as preparation for patches that will eliminate the indirect
>> comparison calls in common cases.
>
> Acked-by: Andrew Morton
>
>> --- a/lib/sort.c
>> +++ b/lib/sort.c
>> @@ -144,6 +144,18 @@ static void do_swap(void *a, void *b, size_t size,
>> swap_func_t swap_func)
>> swap_func(a, b, (int)size);
>> }
>>
>> +typedef int (*cmp_func_t)(const void *, const void *);
>> +typedef int (*cmp_r_func_t)(const void *, const void *, const void *);
>> +#define _CMP_WRAPPER ((cmp_r_func_t)0L)
>
> Although I can't say I'm a fan of _CMP_WRAPPER. I don't understand
> what the name means. Why not simply open-code NULL in the two sites?
That's the preparation part. Once I find time to tie up the loose ends,
there'll be a
sort_by_key(base, num, swap, key)
where base must be a pointer to (array of) struct foobar, and key is the
name of an u32 or u64 (more can be added) member. Internally, that will
work by calling sort_r with a sentinel _CMP_SORT_U32 (or _CMP_SORT_U64,
...) as cmp function and offsetof(typeof(*base), key) as the priv argument.
In do_cmp, we then check whether the cmp function is a small
non-negative integer and then do the appropriate comparison directly
instead of doing an indirect call.
And this infrastructure will be shared with list_sort which will grow a
similar list_sort_by_key(). I think the actual value of _CMP_WRAPPER
will change to simplify that part, so for that reason alone I won't
hard-code NULL.
>> +static int do_cmp(const void *a, const void *b,
>> + cmp_r_func_t cmp, const void *priv)
>> +{
>> +if (cmp == _CMP_WRAPPER)
>> +return ((cmp_func_t)(priv))(a, b);
>> +return cmp(a, b, priv);
>> +}
>> +
i.e., this becomes something like
if ((unsigned long)cmp <= ...) {
if (cmp == CMP_WRAPPER)
// called from sort(), priv is the original cmp_func pointer
return ((cmp_func_t)(priv))(a, b);
// must be called from sort_by_key, priv is the offset in each struct
long offset = (long)priv;
a += offset;
b += offset;
if (cmp == CMP_U32)
return *(u32*)a > *(u32*)b;
if (cmp == CMP_u64)
return *(u64*)a > *(u64*)b;
WARN_ONCE() // should be eliminated by smart enough compiler
return 0;
}
return cmp(a, b, priv);
>> /**
>> * parent - given the offset of the child, find the offset of the parent.
>> * @i: the offset of the heap element whose parent is sought. Non-zero.
>> @@ -171,12 +183,13 @@ static size_t parent(size_t i, unsigned int lsbit,
>> size_t size)
>> }
>>
>> /**
>> - * sort - sort an array of elements
>> + * sort_r - sort an array of elements
>> * @base: pointer to data to sort
>> * @num: number of elements
>> * @size: size of each element
>> * @cmp_func: pointer to comparison function
>> * @swap_func: pointer to swap function or NULL
>> + * @priv: third argument passed to comparison function
>
> Passing priv==NULLis part of the interface and should be documented?
No, to sort_r() as a public function @priv is completely opaque, and the
user can pass anything he likes. Only when sort_r() is called
"internally" with a sentinel value of cmp_func (e.g. from sort() or
sort_by_key()) does the priv argument have any meaning, but that's
implementation details that should absolutely not be documented.
Rasmus
Re: [PATCH 4/5] IMA: use obj-y for non-modular objects
On Fri, Jul 26, 2019 at 1:37 PM Eric Biggers wrote: > > On Fri, Jul 26, 2019 at 11:10:57AM +0900, Masahiro Yamada wrote: > > CONFIG_IMA is a boolean option, so none of these objects is linked > > into a module. > > > > All the objects in this directory are compiled only when CONFIG_IMA=y > > since this directory is guarded by the parent Makefile: > > > > obj-$(CONFIG_IMA) += ima/ > > > > So, there is no point in creating the composite object, ima.o > > > > Flatten the code into the obj-$(CONFIG_...) form. > > > > Signed-off-by: Masahiro Yamada > > --- > > > > security/integrity/ima/Makefile | 8 +++- > > 1 file changed, 3 insertions(+), 5 deletions(-) > > > > diff --git a/security/integrity/ima/Makefile > > b/security/integrity/ima/Makefile > > index d921dc4f9eb0..5517486c9154 100644 > > --- a/security/integrity/ima/Makefile > > +++ b/security/integrity/ima/Makefile > > @@ -4,10 +4,8 @@ > > # Measurement Architecture(IMA). > > # > > > > -obj-$(CONFIG_IMA) += ima.o > > - > > -ima-y := ima_fs.o ima_queue.o ima_init.o ima_main.o ima_crypto.o ima_api.o > > \ > > +obj-y := ima_fs.o ima_queue.o ima_init.o ima_main.o ima_crypto.o ima_api.o > > \ > >ima_policy.o ima_template.o ima_template_lib.o > > -ima-$(CONFIG_IMA_APPRAISE) += ima_appraise.o > > -ima-$(CONFIG_HAVE_IMA_KEXEC) += ima_kexec.o > > +obj-$(CONFIG_IMA_APPRAISE) += ima_appraise.o > > +obj-$(CONFIG_HAVE_IMA_KEXEC) += ima_kexec.o > > obj-$(CONFIG_IMA_BLACKLIST_KEYRING) += ima_mok.o > > -- > > This patch changes the kernel command line options > > ima.ahash_minsize > ima.ahash_bufsize > > to > ima_crypto.ahash_minsize > ima_crypto.ahash_bufsize > > Intentional? No. I missed those kernel parameters. So, please drop this patch. I see no problem in 3/5, 5/5, but if composite object is preferred for consistency, please feel free to drop them as well. Thanks. > Note that these are documented in > Documentation/admin-guide/kernel-parameters.txt. -- Best Regards Masahiro Yamada
Re: [RFC PATCH 00/10] implement KASLR for powerpc/fsl_booke/32
Hi Jason, I have briefly tested yesterday on a P4080 board and did not see any issues. I do not have much expertise on KASLR, but I will take a look over the code. Regards, Diana On 7/25/2019 10:16 AM, Jason Yan wrote: > Hi all, any comments? > > > On 2019/7/17 16:06, Jason Yan wrote: >> This series implements KASLR for powerpc/fsl_booke/32, as a security >> feature that deters exploit attempts relying on knowledge of the location >> of kernel internals. >> >> Since CONFIG_RELOCATABLE has already supported, what we need to do is >> map or copy kernel to a proper place and relocate. Freescale Book-E >> parts expect lowmem to be mapped by fixed TLB entries(TLB1). The TLB1 >> entries are not suitable to map the kernel directly in a randomized >> region, so we chose to copy the kernel to a proper place and restart to >> relocate. >> >> Entropy is derived from the banner and timer base, which will change every >> build and boot. This not so much safe so additionally the bootloader may >> pass entropy via the /chosen/kaslr-seed node in device tree. >> >> We will use the first 512M of the low memory to randomize the kernel >> image. The memory will be split in 64M zones. We will use the lower 8 >> bit of the entropy to decide the index of the 64M zone. Then we chose a >> 16K aligned offset inside the 64M zone to put the kernel in. >> >> KERNELBASE >> >> |--> 64M <--| >> | | >> +---+++---+ >> | |||kernel|| | >> +---+++---+ >> | | >> |-> offset<-| >> >>kimage_vaddr >> >> We also check if we will overlap with some areas like the dtb area, the >> initrd area or the crashkernel area. If we cannot find a proper area, >> kaslr will be disabled and boot from the original kernel. >> >> Jason Yan (10): >>powerpc: unify definition of M_IF_NEEDED >>powerpc: move memstart_addr and kernstart_addr to init-common.c >>powerpc: introduce kimage_vaddr to store the kernel base >>powerpc/fsl_booke/32: introduce create_tlb_entry() helper >>powerpc/fsl_booke/32: introduce reloc_kernel_entry() helper >>powerpc/fsl_booke/32: implement KASLR infrastructure >>powerpc/fsl_booke/32: randomize the kernel image offset >>powerpc/fsl_booke/kaslr: clear the original kernel if randomized >>powerpc/fsl_booke/kaslr: support nokaslr cmdline parameter >>powerpc/fsl_booke/kaslr: dump out kernel offset information on panic >> >> arch/powerpc/Kconfig | 11 + >> arch/powerpc/include/asm/nohash/mmu-book3e.h | 10 + >> arch/powerpc/include/asm/page.h | 7 + >> arch/powerpc/kernel/Makefile | 1 + >> arch/powerpc/kernel/early_32.c| 2 +- >> arch/powerpc/kernel/exceptions-64e.S | 10 - >> arch/powerpc/kernel/fsl_booke_entry_mapping.S | 23 +- >> arch/powerpc/kernel/head_fsl_booke.S | 61 ++- >> arch/powerpc/kernel/kaslr_booke.c | 439 ++ >> arch/powerpc/kernel/machine_kexec.c | 1 + >> arch/powerpc/kernel/misc_64.S | 5 - >> arch/powerpc/kernel/setup-common.c| 23 + >> arch/powerpc/mm/init-common.c | 7 + >> arch/powerpc/mm/init_32.c | 5 - >> arch/powerpc/mm/init_64.c | 5 - >> arch/powerpc/mm/mmu_decl.h| 10 + >> arch/powerpc/mm/nohash/fsl_booke.c| 8 +- >> 17 files changed, 580 insertions(+), 48 deletions(-) >> create mode 100644 arch/powerpc/kernel/kaslr_booke.c >> >
Re: [alsa-devel] [RFC PATCH 15/40] soundwire: cadence_master: handle multiple status reports per Slave
On Thu, Jul 25, 2019 at 06:40:07PM -0500, Pierre-Louis Bossart wrote:
> When a Slave reports multiple status in the sticky bits, find the
> latest configuration from the mirror of the PING frame status and
> update the status directly.
>
> Signed-off-by: Pierre-Louis Bossart
> ---
> drivers/soundwire/cadence_master.c | 34 --
> 1 file changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/soundwire/cadence_master.c
> b/drivers/soundwire/cadence_master.c
> index 889fa2cd49ae..25d5c7267c15 100644
> --- a/drivers/soundwire/cadence_master.c
> +++ b/drivers/soundwire/cadence_master.c
> @@ -643,13 +643,35 @@ static int cdns_update_slave_status(struct sdw_cdns
> *cdns,
>
> /* first check if Slave reported multiple status */
> if (set_status > 1) {
> + u32 val;
> +
> dev_warn_ratelimited(cdns->dev,
> - "Slave reported multiple Status:
> %d\n",
> - mask);
> - /*
> - * TODO: we need to reread the status here by
> - * issuing a PING cmd
> - */
> + "Slave %d reported multiple
> Status: %d\n",
> + i, mask);
> +
> + /* re-check latest status extracted from PING commands
> */
> + val = cdns_readl(cdns, CDNS_MCP_SLAVE_STAT);
> + val >>= (i * 2);
Superfluous parentheses.
> +
> + switch (val & 0x3) {
> + case 0:
> + status[i] = SDW_SLAVE_UNATTACHED;
> + break;
> + case 1:
> + status[i] = SDW_SLAVE_ATTACHED;
> + break;
> + case 2:
> + status[i] = SDW_SLAVE_ALERT;
> + break;
> + default:
There aren't many values left for the "default" case :-) But I'm not sure
whether
any of
+ case 3:
or
+ case 3:
+ default:
would improve readability.
Thanks
Guennadi
> + status[i] = SDW_SLAVE_RESERVED;
> + break;
> + }
> +
> + dev_warn_ratelimited(cdns->dev,
> + "Slave %d status updated to %d\n",
> + i, status[i]);
> +
> }
> }
>
> --
> 2.20.1
>
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Re: [Regression] Missing device nodes for ETR, ETF and STM after CONFIG_UEVENT_HELPER=n
On Fri, Jul 26, 2019 at 11:49:19AM +0530, Sai Prakash Ranjan wrote:
> Hi,
>
> When trying to test my coresight patches, I found that etr,etf and stm
> device nodes are missing from /dev.
I have no idea what those device nodes are.
> Bisection gives this as the bad commit.
>
> 1be01d4a57142ded23bdb9e0c8d9369e693b26cc is the first bad commit
> commit 1be01d4a57142ded23bdb9e0c8d9369e693b26cc
> Author: Geert Uytterhoeven
> Date: Thu Mar 14 12:13:50 2019 +0100
>
> driver: base: Disable CONFIG_UEVENT_HELPER by default
>
> Since commit 7934779a69f1184f ("Driver-Core: disable /sbin/hotplug by
> default"), the help text for the /sbin/hotplug fork-bomb says
> "This should not be used today [...] creates a high system load, or
> [...] out-of-memory situations during bootup". The rationale for this
> was that no recent mainstream system used this anymore (in 2010!).
>
> A few years later, the complete uevent helper support was made optional
> in commit 86d56134f1b67d0c ("kobject: Make support for uevent_helper
> optional."). However, if was still left enabled by default, to support
> ancient userland.
>
> Time passed by, and nothing should use this anymore, so it can be
> disabled by default.
>
> Signed-off-by: Geert Uytterhoeven
> Signed-off-by: Greg Kroah-Hartman
>
> drivers/base/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
>
> Any idea on this?
That means that who ever created those device nodes is relying on udev
to do this, and is not doing the correct thing within the kernel and
using devtmpfs.
Any pointers to where in the kernel those devices are trying to be
created?
thanks,
greg k-h
Re: [PATCH 2/2] /proc/kpageflags: do not use uninitialized struct pages
On Fri 26-07-19 06:25:49, Toshiki Fukasawa wrote: > > > On 2019/07/25 18:03, Michal Hocko wrote: > > On Thu 25-07-19 02:31:18, Toshiki Fukasawa wrote: > >> A kernel panic was observed during reading /proc/kpageflags for > >> first few pfns allocated by pmem namespace: > >> > >> BUG: unable to handle page fault for address: fffe > >> [ 114.495280] #PF: supervisor read access in kernel mode > >> [ 114.495738] #PF: error_code(0x) - not-present page > >> [ 114.496203] PGD 17120e067 P4D 17120e067 PUD 171210067 PMD 0 > >> [ 114.496713] Oops: [#1] SMP PTI > >> [ 114.497037] CPU: 9 PID: 1202 Comm: page-types Not tainted 5.3.0-rc1 #1 > >> [ 114.497621] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > >> rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014 > >> [ 114.498706] RIP: 0010:stable_page_flags+0x27/0x3f0 > >> [ 114.499142] Code: 82 66 90 66 66 66 66 90 48 85 ff 0f 84 d1 03 00 00 41 > >> 54 55 48 89 fd 53 48 8b 57 08 48 8b 1f 48 8d 42 ff 83 e2 01 48 0f 44 c7 > >> <48> 8b 00 f6 c4 02 0f 84 57 03 00 00 45 31 e4 48 8b 55 08 48 89 ef > >> [ 114.500788] RSP: 0018:a5e601a0fe60 EFLAGS: 00010202 > >> [ 114.501373] RAX: fffe RBX: RCX: > >> > >> [ 114.502009] RDX: 0001 RSI: 7ffca13a7310 RDI: > >> d0748900 > >> [ 114.502637] RBP: d0748900 R08: 0001 R09: > >> > >> [ 114.503270] R10: R11: R12: > >> 0024 > >> [ 114.503896] R13: 0008 R14: 7ffca13a7310 R15: > >> a5e601a0ff08 > >> [ 114.504530] FS: 7f0266c7f540() GS:962dbbac() > >> knlGS: > >> [ 114.505245] CS: 0010 DS: ES: CR0: 80050033 > >> [ 114.505754] CR2: fffe CR3: 00023a204000 CR4: > >> 06e0 > >> [ 114.506401] Call Trace: > >> [ 114.506660] kpageflags_read+0xb1/0x130 > >> [ 114.507051] proc_reg_read+0x39/0x60 > >> [ 114.507387] vfs_read+0x8a/0x140 > >> [ 114.507686] ksys_pread64+0x61/0xa0 > >> [ 114.508021] do_syscall_64+0x5f/0x1a0 > >> [ 114.508372] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > >> [ 114.508844] RIP: 0033:0x7f0266ba426b > >> > >> The reason for the panic is that stable_page_flags() which parses > >> the page flags uses uninitialized struct pages reserved by the > >> ZONE_DEVICE driver. > > > > Why pmem hasn't initialized struct pages? > > We proposed to initialize in previous approach but that wasn't merged. > (See https://marc.info/?l=linux-mm=152964792500739=2) > > > Isn't that a bug that should be addressed rather than paper over it like > > this? > > I'm not sure. What do you think, Dan? Yeah, I am really curious about details. Why do we keep uninitialized struct pages at all? What is a random pfn walker supposed to do? What kind of metadata would be clobbered? In other words much more details please. -- Michal Hocko SUSE Labs
Re: [PATCH 00/10] make "order" unsigned int
On Fri 26-07-19 07:48:36, Pengfei Li wrote: [...] > For the benefit, "order" may be negative, which is confusing and weird. order = -1 has a special meaning. > There is no good reason not to do this since it can be avoided. "This is good because we can do it" doesn't really sound like a convincing argument to me. I would understand if this reduced a generated code, made an overall code readability much better or something along those lines. Also we only use MAX_ORDER range of values so I could argue that a smaller data type (e.g. short) should be sufficient for this data type. Please note that _any_ change, alebit seemingly small, can introduce a subtle bug. Also each patch requires a man power to review so you have to understand that "just because we can" is not a strong motivation for people to spend their time on such a patch. -- Michal Hocko SUSE Labs
Re: [PATCH v5] serial/8250: Add support for NI-Serial PXI/PXIe+485 devices
On Fri, Jul 26, 2019 at 10:40:46AM +0800, jeyentam wrote: > Add support for NI-Serial PXIe-RS232, PXI-RS485 and PXIe-RS485 devices. > > Signed-off-by: jeyentam You messed up the From: and signed-off-by: lines this time :( v4 had it "correct", please fix up and send v6. thanks, greg k-h
RE: Re: [PATCH v5] serial/8250: Add support for NI-Serial PXI/PXIe+485 devices
> Subject: [EXTERNAL] Re: [PATCH v5] serial/8250: Add support for NI-Serial > PXI/PXIe+485 devices > > On Fri, Jul 26, 2019 at 10:40:46AM +0800, jeyentam wrote: > > Add support for NI-Serial PXIe-RS232, PXI-RS485 and PXIe-RS485 devices. > > > > Signed-off-by: jeyentam > > You messed up the From: and signed-off-by: lines this time :( > > v4 had it "correct", please fix up and send v6. Oh snap, will fix it in v6. > > thanks, > > greg k-h
Re: [PATCH] KVM: X86: Use IPI shorthands in kvm guest when support
On Fri, 26 Jul 2019, Wanpeng Li wrote:
> On Fri, 26 Jul 2019 at 14:10, Wanpeng Li wrote:
> > static void kvm_send_ipi_all(int vector)
> > {
> > - __send_ipi_mask(cpu_online_mask, vector);
> > + if (static_branch_likely(_use_ipi_shorthand))
> > + orig_apic.send_IPI_allbutself(vector);
>
> Make a mistake here, just resend the patch.
Please don't use [RESEND] if the patch is different. Use [PATCH v2].
[RESEND] is used when you actually resend an unmodified patch, e.g. when
the first submission was ignored for a longer time.
Thanks,
tglx
Re: [RFC PATCH 00/10] implement KASLR for powerpc/fsl_booke/32
On 2019/7/26 3:58, Kees Cook wrote: On Thu, Jul 25, 2019 at 03:16:28PM +0800, Jason Yan wrote: Hi all, any comments? I'm a fan of it, but I don't know ppc internals well enough to sanely review the code. :) Some comments below on design... Hi Kees, Thanks for your comments. On 2019/7/17 16:06, Jason Yan wrote: This series implements KASLR for powerpc/fsl_booke/32, as a security feature that deters exploit attempts relying on knowledge of the location of kernel internals. Since CONFIG_RELOCATABLE has already supported, what we need to do is map or copy kernel to a proper place and relocate. Freescale Book-E parts expect lowmem to be mapped by fixed TLB entries(TLB1). The TLB1 entries are not suitable to map the kernel directly in a randomized region, so we chose to copy the kernel to a proper place and restart to relocate. Entropy is derived from the banner and timer base, which will change every build and boot. This not so much safe so additionally the bootloader may pass entropy via the /chosen/kaslr-seed node in device tree. Good: adding kaslr-seed is a good step here. Are there any x86-like RDRAND or RDTSC to use? (Or maybe timer base here is similar to x86 RDTSC here?) Yes, time base is similar to RDTSC here. We will use the first 512M of the low memory to randomize the kernel image. The memory will be split in 64M zones. We will use the lower 8 bit of the entropy to decide the index of the 64M zone. Then we chose a 16K aligned offset inside the 64M zone to put the kernel in. Does this 16K granularity have any page table performance impact? My understanding was that x86 needed to have 2M granularity due to its page table layouts. The fsl booke TLB1 covers the whole low memeory. AFAIK, there is no page table performance impact. But if anyone knows there is any regressions, please let me know. Why the 64M zones instead of just 16K granularity across the entire low 512M? The boot code only maps one 64M zone at early start. If the kernel crosses two 64M zones, we need to map two 64M zones. Keep the kernel in one 64M saves a lot of complex codes. KERNELBASE |--> 64M <--| | | +---+++---+ | |||kernel|| | +---+++---+ | | |-> offset<-| kimage_vaddr We also check if we will overlap with some areas like the dtb area, the initrd area or the crashkernel area. If we cannot find a proper area, kaslr will be disabled and boot from the original kernel. Jason Yan (10): powerpc: unify definition of M_IF_NEEDED powerpc: move memstart_addr and kernstart_addr to init-common.c powerpc: introduce kimage_vaddr to store the kernel base powerpc/fsl_booke/32: introduce create_tlb_entry() helper powerpc/fsl_booke/32: introduce reloc_kernel_entry() helper powerpc/fsl_booke/32: implement KASLR infrastructure powerpc/fsl_booke/32: randomize the kernel image offset powerpc/fsl_booke/kaslr: clear the original kernel if randomized powerpc/fsl_booke/kaslr: support nokaslr cmdline parameter powerpc/fsl_booke/kaslr: dump out kernel offset information on panic Is there anything planned for other fixed-location things, like x86's CONFIG_RANDOMIZE_MEMORY? Yes, if this feature can be accepted, I will start to work with powerpc64 KASLR and other things like CONFIG_RANDOMIZE_MEMORY.
[PATCH 0/6] Optimize Spreadtrum ADI driver
This patchset did some optimization to remove some redundant code, add more reboot mode support and change hardware spinlock support to be optional. Baolin Wang (3): spi: sprd: adi: Remove redundant address bits setting spi: sprd: adi: Change hwlock to be optional dt-bindings: spi: sprd: Change the hwlock support to be optional Chenxu Wei (1): spi: sprd: adi: Add a reset reason for TOS panic Sherry Zong (2): spi: sprd: adi: Add a reset reason for factory test mode spi: sprd: adi: Add a reset reason for watchdog mode .../devicetree/bindings/spi/spi-sprd-adi.txt | 11 ++- drivers/spi/spi-sprd-adi.c | 92 ++-- 2 files changed, 71 insertions(+), 32 deletions(-) -- 1.7.9.5
[PATCH 1/6] spi: sprd: adi: Remove redundant address bits setting
The ADI default transfer address bits is 12bit on Spreadtrum SC9860 platform, thus there is no need to set again, remove it. Signed-off-by: Baolin Wang --- drivers/spi/spi-sprd-adi.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/spi/spi-sprd-adi.c b/drivers/spi/spi-sprd-adi.c index df5960b..11880db 100644 --- a/drivers/spi/spi-sprd-adi.c +++ b/drivers/spi/spi-sprd-adi.c @@ -380,9 +380,6 @@ static void sprd_adi_hw_init(struct sprd_adi *sadi) const __be32 *list; u32 tmp; - /* Address bits select default 12 bits */ - writel_relaxed(0, sadi->base + REG_ADI_CTRL0); - /* Set all channels as default priority */ writel_relaxed(0, sadi->base + REG_ADI_CHN_PRIL); writel_relaxed(0, sadi->base + REG_ADI_CHN_PRIH); -- 1.7.9.5
Re: [PATCH v1] ACPI / scan: Acquire device_hotplug_lock in acpi_scan_init()
On 25.07.19 23:23, Rafael J. Wysocki wrote: > On Thu, Jul 25, 2019 at 10:49 PM David Hildenbrand wrote: >> >> On 25.07.19 21:19, Michal Hocko wrote: >>> On Thu 25-07-19 16:35:07, David Hildenbrand wrote: On 25.07.19 15:57, Michal Hocko wrote: > On Thu 25-07-19 15:05:02, David Hildenbrand wrote: >> On 25.07.19 14:56, Michal Hocko wrote: >>> On Wed 24-07-19 16:30:17, David Hildenbrand wrote: We end up calling __add_memory() without the device hotplug lock held. (I used a local patch to assert in __add_memory() that the device_hotplug_lock is held - I might upstream that as well soon) [ 26.771684]create_memory_block_devices+0xa4/0x140 [ 26.772952]add_memory_resource+0xde/0x200 [ 26.773987]__add_memory+0x6e/0xa0 [ 26.775161]acpi_memory_device_add+0x149/0x2b0 [ 26.776263]acpi_bus_attach+0xf1/0x1f0 [ 26.777247]acpi_bus_attach+0x66/0x1f0 [ 26.778268]acpi_bus_attach+0x66/0x1f0 [ 26.779073]acpi_bus_attach+0x66/0x1f0 [ 26.780143]acpi_bus_scan+0x3e/0x90 [ 26.780844]acpi_scan_init+0x109/0x257 [ 26.781638]acpi_init+0x2ab/0x30d [ 26.782248]do_one_initcall+0x58/0x2cf [ 26.783181]kernel_init_freeable+0x1bd/0x247 [ 26.784345]kernel_init+0x5/0xf1 [ 26.785314]ret_from_fork+0x3a/0x50 So perform the locking just like in acpi_device_hotplug(). >>> >>> While playing with the device_hotplug_lock, can we actually document >>> what it is protecting please? I have a bad feeling that we are adding >>> this lock just because some other code path does rather than with a good >>> idea why it is needed. This patch just confirms that. What exactly does >>> the lock protect from here in an early boot stage. >> >> We have plenty of documentation already >> >> mm/memory_hotplug.c >> >> git grep -C5 device_hotplug mm/memory_hotplug.c >> >> Also see >> >> Documentation/core-api/memory-hotplug.rst > > OK, fair enough. I was more pointing to a documentation right there > where the lock is declared because that is the place where people > usually check for documentation. The core-api documentation looks quite > nice. And based on that doc it seems that this patch is actually not > needed because neither the online/offline or cpu hotplug should be > possible that early unless I am missing something. I really prefer to stick to locking rules as outlined on the interfaces if it doesn't hurt. Why it is not needed is not clear. > >> Regarding the early stage: primarily lockdep as I mentioned. > > Could you add a lockdep splat that would be fixed by this patch to the > changelog for reference? > I have one where I enforce what's documented (but that's of course not upstream and therefore not "real" yet) >>> >>> Then I suppose to not add locking for something that is not a problem. >>> Really, think about it. People will look at this code and follow the >>> lead without really knowing why the locking is needed. >>> device_hotplug_lock has its purpose and if the code in question doesn't >>> need synchronization for the documented scenarios then the locking >>> simply shouldn't be there. Adding the lock just because of a >>> non-existing, and IMHO dubious, lockdep splats is just wrong. >>> >>> We need to rationalize the locking here, not to add more hacks. >> >> No, sorry. The real hack is calling a function that is *documented* to >> be called under lock without it. That is an optimization for a special >> case. That is the black magic in the code. >> >> The only alternative I see to this patch is adding a comment like >> >> /* >> * We end up calling __add_memory() without the device_hotplug_lock >> * held. This is fine as we cannot race with other hotplug activities >> * and userspace trying to online memory blocks. >> */ >> >> Personally, I don't think that's any better than just grabbing the lock >> as we are told to. (honestly, I don't see how optimizing away the lock >> here is of *any* help to optimize our overall memory hotplug locking) >> >> @Rafael, what's your take? lock or comment? > > Well, I have ACKed your patch already. :-) It's never to late to un-ACK if you changed your mind :) > > That said, adding a comment stating that the lock is acquired mostly > for consistency wouldn't hurt. > I can certainly do that. Thanks! -- Thanks, David / dhildenb
[PATCH 2/6] spi: sprd: adi: Add a reset reason for TOS panic
From: Chenxu Wei Add a new reset flag to indicate the reset reason is caused by TOS. Signed-off-by: Chenxu Wei Signed-off-by: Baolin Wang --- drivers/spi/spi-sprd-adi.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/spi/spi-sprd-adi.c b/drivers/spi/spi-sprd-adi.c index 11880db..0b3f23a 100644 --- a/drivers/spi/spi-sprd-adi.c +++ b/drivers/spi/spi-sprd-adi.c @@ -86,6 +86,7 @@ #define BIT_WDG_EN BIT(2) /* Definition of PMIC reset status register */ +#define HWRST_STATUS_SECURITY 0x02 #define HWRST_STATUS_RECOVERY 0x20 #define HWRST_STATUS_NORMAL0x40 #define HWRST_STATUS_ALARM 0x50 @@ -336,6 +337,8 @@ static int sprd_adi_restart_handler(struct notifier_block *this, reboot_mode = HWRST_STATUS_IQMODE; else if (!strncmp(cmd, "sprdisk", 7)) reboot_mode = HWRST_STATUS_SPRDISK; + else if (!strncmp(cmd, "tospanic", 8)) + reboot_mode = HWRST_STATUS_SECURITY; else reboot_mode = HWRST_STATUS_NORMAL; -- 1.7.9.5
[PATCH 3/6] spi: sprd: adi: Add a reset reason for factory test mode
From: Sherry Zong Add a new reset flag to indicate that the system need enter factory test mode after restarting system. Signed-off-by: Sherry Zong Signed-off-by: Baolin Wang --- drivers/spi/spi-sprd-adi.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/spi/spi-sprd-adi.c b/drivers/spi/spi-sprd-adi.c index 0b3f23a..509ce69 100644 --- a/drivers/spi/spi-sprd-adi.c +++ b/drivers/spi/spi-sprd-adi.c @@ -98,6 +98,7 @@ #define HWRST_STATUS_AUTODLOADER 0xa0 #define HWRST_STATUS_IQMODE0xb0 #define HWRST_STATUS_SPRDISK 0xc0 +#define HWRST_STATUS_FACTORYTEST 0xe0 /* Use default timeout 50 ms that converts to watchdog values */ #define WDG_LOAD_VAL ((50 * 1000) / 32768) @@ -339,6 +340,8 @@ static int sprd_adi_restart_handler(struct notifier_block *this, reboot_mode = HWRST_STATUS_SPRDISK; else if (!strncmp(cmd, "tospanic", 8)) reboot_mode = HWRST_STATUS_SECURITY; + else if (!strncmp(cmd, "factorytest", 11)) + reboot_mode = HWRST_STATUS_FACTORYTEST; else reboot_mode = HWRST_STATUS_NORMAL; -- 1.7.9.5
[PATCH 6/6] dt-bindings: spi: sprd: Change the hwlock support to be optional
No need to add hardware spinlock proctection due to add multiple msater channel, so change it to be optional in documentation. Signed-off-by: Baolin Wang --- .../devicetree/bindings/spi/spi-sprd-adi.txt | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt b/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt index 8de589b..2567c82 100644 --- a/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt +++ b/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt @@ -25,18 +25,23 @@ data by ADI software channels at the same time, or two parallel routine of setti ADI registers will make ADI controller registers chaos to lead incorrect results. Then we need one hardware spinlock to synchronize between the multiple subsystems. +The new version ADI controller supplies multiple master channels for different +subsystem accessing, that means no need to add hardware spinlock to synchronize, +thus change the hardware spinlock support to be optional to keep backward +compatibility. + Required properties: - compatible: Should be "sprd,sc9860-adi". - reg: Offset and length of ADI-SPI controller register space. -- hwlocks: Reference to a phandle of a hwlock provider node. -- hwlock-names: Reference to hwlock name strings defined in the same order - as the hwlocks, should be "adi". - #address-cells: Number of cells required to define a chip select address on the ADI-SPI bus. Should be set to 1. - #size-cells: Size of cells required to define a chip select address size on the ADI-SPI bus. Should be set to 0. Optional properties: +- hwlocks: Reference to a phandle of a hwlock provider node. +- hwlock-names: Reference to hwlock name strings defined in the same order + as the hwlocks, should be "adi". - sprd,hw-channels: This is an array of channel values up to 49 channels. The first value specifies the hardware channel id which is used to transfer data triggered by hardware automatically, and the second -- 1.7.9.5
[PATCH 4/6] spi: sprd: adi: Add a reset reason for watchdog mode
From: Sherry Zong
When the system was rebooted by watchdog, now we did not save the watchdog
reset mode which will make system enter a incorrect mode after rebooting.
Thus we should set the watchdog reset mode as default when opening the
watchdog configuration, that means if the system was rebooted by other
reason through the restart_handler(), then we will clear the default
watchdog reset mode to save the correct reset mode.
Signed-off-by: Sherry Zong
Signed-off-by: Baolin Wang
---
drivers/spi/spi-sprd-adi.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/spi/spi-sprd-adi.c b/drivers/spi/spi-sprd-adi.c
index 509ce69..0d767eb 100644
--- a/drivers/spi/spi-sprd-adi.c
+++ b/drivers/spi/spi-sprd-adi.c
@@ -99,6 +99,7 @@
#define HWRST_STATUS_IQMODE0xb0
#define HWRST_STATUS_SPRDISK 0xc0
#define HWRST_STATUS_FACTORYTEST 0xe0
+#define HWRST_STATUS_WATCHDOG 0xf0
/* Use default timeout 50 ms that converts to watchdog values */
#define WDG_LOAD_VAL ((50 * 1000) / 32768)
@@ -309,6 +310,18 @@ static int sprd_adi_transfer_one(struct spi_controller
*ctlr,
return 0;
}
+static void sprd_adi_set_wdt_rst_mode(struct sprd_adi *sadi)
+{
+#ifdef CONFIG_SPRD_WATCHDOG
+ u32 val;
+
+ /* Set default watchdog reboot mode */
+ sprd_adi_read(sadi, sadi->slave_pbase + PMIC_RST_STATUS, );
+ val |= HWRST_STATUS_WATCHDOG;
+ sprd_adi_write(sadi, sadi->slave_pbase + PMIC_RST_STATUS, val);
+#endif
+}
+
static int sprd_adi_restart_handler(struct notifier_block *this,
unsigned long mode, void *cmd)
{
@@ -347,6 +360,7 @@ static int sprd_adi_restart_handler(struct notifier_block
*this,
/* Record the reboot mode */
sprd_adi_read(sadi, sadi->slave_pbase + PMIC_RST_STATUS, );
+ val &= ~HWRST_STATUS_WATCHDOG;
val |= reboot_mode;
sprd_adi_write(sadi, sadi->slave_pbase + PMIC_RST_STATUS, val);
@@ -475,6 +489,7 @@ static int sprd_adi_probe(struct platform_device *pdev)
}
sprd_adi_hw_init(sadi);
+ sprd_adi_set_wdt_rst_mode(sadi);
ctlr->dev.of_node = pdev->dev.of_node;
ctlr->bus_num = pdev->id;
--
1.7.9.5
[PATCH 5/6] spi: sprd: adi: Change hwlock to be optional
Now Spreadtrum ADI controller supplies multiple master accessing channel
to support multiple subsystems accessing, instead of using a hardware
spinlock to synchronize between the multiple subsystems.
To keep backward compatibility, we should change the hardware spinlock
to be optional. Moreover change to use of_hwspin_lock_get_id() function
which return -ENOENT error number to indicate no hwlock support.
Signed-off-by: Baolin Wang
---
drivers/spi/spi-sprd-adi.c | 68 +++-
1 file changed, 42 insertions(+), 26 deletions(-)
diff --git a/drivers/spi/spi-sprd-adi.c b/drivers/spi/spi-sprd-adi.c
index 0d767eb..9a05128 100644
--- a/drivers/spi/spi-sprd-adi.c
+++ b/drivers/spi/spi-sprd-adi.c
@@ -165,14 +165,16 @@ static int sprd_adi_read(struct sprd_adi *sadi, u32
reg_paddr, u32 *read_val)
int read_timeout = ADI_READ_TIMEOUT;
unsigned long flags;
u32 val, rd_addr;
- int ret;
-
- ret = hwspin_lock_timeout_irqsave(sadi->hwlock,
- ADI_HWSPINLOCK_TIMEOUT,
- );
- if (ret) {
- dev_err(sadi->dev, "get the hw lock failed\n");
- return ret;
+ int ret = 0;
+
+ if (sadi->hwlock) {
+ ret = hwspin_lock_timeout_irqsave(sadi->hwlock,
+ ADI_HWSPINLOCK_TIMEOUT,
+ );
+ if (ret) {
+ dev_err(sadi->dev, "get the hw lock failed\n");
+ return ret;
+ }
}
/*
@@ -219,7 +221,8 @@ static int sprd_adi_read(struct sprd_adi *sadi, u32
reg_paddr, u32 *read_val)
*read_val = val & RD_VALUE_MASK;
out:
- hwspin_unlock_irqrestore(sadi->hwlock, );
+ if (sadi->hwlock)
+ hwspin_unlock_irqrestore(sadi->hwlock, );
return ret;
}
@@ -230,12 +233,14 @@ static int sprd_adi_write(struct sprd_adi *sadi, u32
reg_paddr, u32 val)
unsigned long flags;
int ret;
- ret = hwspin_lock_timeout_irqsave(sadi->hwlock,
- ADI_HWSPINLOCK_TIMEOUT,
- );
- if (ret) {
- dev_err(sadi->dev, "get the hw lock failed\n");
- return ret;
+ if (sadi->hwlock) {
+ ret = hwspin_lock_timeout_irqsave(sadi->hwlock,
+ ADI_HWSPINLOCK_TIMEOUT,
+ );
+ if (ret) {
+ dev_err(sadi->dev, "get the hw lock failed\n");
+ return ret;
+ }
}
ret = sprd_adi_drain_fifo(sadi);
@@ -261,7 +266,8 @@ static int sprd_adi_write(struct sprd_adi *sadi, u32
reg_paddr, u32 val)
}
out:
- hwspin_unlock_irqrestore(sadi->hwlock, );
+ if (sadi->hwlock)
+ hwspin_unlock_irqrestore(sadi->hwlock, );
return ret;
}
@@ -476,16 +482,26 @@ static int sprd_adi_probe(struct platform_device *pdev)
sadi->slave_pbase = res->start + ADI_SLAVE_OFFSET;
sadi->ctlr = ctlr;
sadi->dev = >dev;
- ret = of_hwspin_lock_get_id_byname(np, "adi");
- if (ret < 0) {
- dev_err(>dev, "can not get the hardware spinlock\n");
- goto put_ctlr;
- }
-
- sadi->hwlock = devm_hwspin_lock_request_specific(>dev, ret);
- if (!sadi->hwlock) {
- ret = -ENXIO;
- goto put_ctlr;
+ ret = of_hwspin_lock_get_id(np, 0);
+ if (ret > 0 || (IS_ENABLED(CONFIG_HWSPINLOCK) && ret == 0)) {
+ sadi->hwlock =
+ devm_hwspin_lock_request_specific(>dev, ret);
+ if (!sadi->hwlock) {
+ ret = -ENXIO;
+ goto put_ctlr;
+ }
+ } else {
+ switch (ret) {
+ case -ENOENT:
+ dev_info(>dev, "no hardware spinlock supplied\n");
+ break;
+ default:
+ dev_err(>dev,
+ "failed to find hwlock id, %d\n", ret);
+ /* fall-through */
+ case -EPROBE_DEFER:
+ goto put_ctlr;
+ }
}
sprd_adi_hw_init(sadi);
--
1.7.9.5
[PATCH v6] serial/8250: Add support for NI-Serial PXI/PXIe+485 devices
Add support for NI-Serial PXIe-RS232, PXI-RS485 and PXIe-RS485 devices.
Signed-off-by: Je Yen Tam
---
v5 -> v6
- Fix author full name.
v4 -> v5
- Remove blank lines between variable definitions.
- Remove trace_printk().
v3 -> v4:
- Add changes description.
v2 -> v3:
- Add "full" name for author
- Use BIT() macro for bits definition
- Remove unnecessary WARN_ON()
- Change debugging interface to ftrace
- Fix indentation
- Add NI PXIe-RS232 and PXI/PXIe-RS485 device IDs #defines
v1 -> v2:
- Fix unintended indentation
v1:
- Add and rename #defines for 16550 UART Port Control Register
- Add configuration for RS485 port.
- Add device setup for NI PXI/PXIe-RS485 family.
- Add PCI board attributes for NI PXIe-RS232 and PXI/PXIe-RS485 devices.
drivers/tty/serial/8250/8250_pci.c | 292 -
1 file changed, 288 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_pci.c
b/drivers/tty/serial/8250/8250_pci.c
index df41397de478..a675069571b2 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -730,8 +730,16 @@ static int pci_ni8430_init(struct pci_dev *dev)
}
/* UART Port Control Register */
-#define NI8430_PORTCON 0x0f
-#define NI8430_PORTCON_TXVR_ENABLE (1 << 3)
+#define NI16550_PCR_OFFSET 0x0f
+#define NI16550_PCR_RS422 0x00
+#define NI16550_PCR_ECHO_RS485 0x01
+#define NI16550_PCR_DTR_RS485 0x02
+#define NI16550_PCR_AUTO_RS485 0x03
+#define NI16550_PCR_WIRE_MODE_MASK 0x03
+#define NI16550_PCR_TXVR_ENABLE_BITBIT(3)
+#define NI16550_PCR_RS485_TERMINATION_BIT BIT(6)
+#define NI16550_ACR_DTR_AUTO_DTR (0x2 << 3)
+#define NI16550_ACR_DTR_MANUAL_DTR (0x0 << 3)
static int
pci_ni8430_setup(struct serial_private *priv,
@@ -753,14 +761,117 @@ pci_ni8430_setup(struct serial_private *priv,
return -ENOMEM;
/* enable the transceiver */
- writeb(readb(p + offset + NI8430_PORTCON) | NI8430_PORTCON_TXVR_ENABLE,
- p + offset + NI8430_PORTCON);
+ writeb(readb(p + offset + NI16550_PCR_OFFSET) |
NI16550_PCR_TXVR_ENABLE_BIT,
+ p + offset + NI16550_PCR_OFFSET);
iounmap(p);
return setup_port(priv, port, bar, offset, board->reg_shift);
}
+static int pci_ni8431_config_rs485(struct uart_port *port,
+ struct serial_rs485 *rs485)
+{
+ u8 pcr, acr;
+ struct uart_8250_port *up;
+
+ up = container_of(port, struct uart_8250_port, port);
+ acr = up->acr;
+ pcr = port->serial_in(port, NI16550_PCR_OFFSET);
+ pcr &= ~NI16550_PCR_WIRE_MODE_MASK;
+
+ if (rs485->flags & SER_RS485_ENABLED) {
+ /* RS-485 */
+ if ((rs485->flags & SER_RS485_RX_DURING_TX) &&
+ (rs485->flags & SER_RS485_RTS_ON_SEND)) {
+ dev_dbg(port->dev, "Invalid 2-wire mode\n");
+ return -EINVAL;
+ }
+
+ if (rs485->flags & SER_RS485_RX_DURING_TX) {
+ /* Echo */
+ dev_vdbg(port->dev, "2-wire DTR with echo\n");
+ pcr |= NI16550_PCR_ECHO_RS485;
+ acr |= NI16550_ACR_DTR_MANUAL_DTR;
+ } else {
+ /* Auto or DTR */
+ if (rs485->flags & SER_RS485_RTS_ON_SEND) {
+ /* Auto */
+ dev_vdbg(port->dev, "2-wire Auto\n");
+ pcr |= NI16550_PCR_AUTO_RS485;
+ acr |= NI16550_ACR_DTR_AUTO_DTR;
+ } else {
+ /* DTR-controlled */
+ /* No Echo */
+ dev_vdbg(port->dev, "2-wire DTR no echo\n");
+ pcr |= NI16550_PCR_DTR_RS485;
+ acr |= NI16550_ACR_DTR_MANUAL_DTR;
+ }
+ }
+ } else {
+ /* RS-422 */
+ dev_vdbg(port->dev, "4-wire\n");
+ pcr |= NI16550_PCR_RS422;
+ acr |= NI16550_ACR_DTR_MANUAL_DTR;
+ }
+
+ dev_dbg(port->dev, "write pcr: 0x%08x\n", pcr);
+ port->serial_out(port, NI16550_PCR_OFFSET, pcr);
+
+ up->acr = acr;
+ port->serial_out(port, UART_SCR, UART_ACR);
+ port->serial_out(port, UART_ICR, up->acr);
+
+ /* Update the cache. */
+ port->rs485 = *rs485;
+
+ return 0;
+}
+
+static int pci_ni8431_setup(struct serial_private *priv,
+const struct pciserial_board *board,
+struct uart_8250_port *uart, int idx)
+{
+ u8 pcr, acr;
+ struct pci_dev *dev = priv->dev;
+ void __iomem *addr;
+ unsigned int bar, offset = board->first_offset;
+
+ if (idx >= board->num_ports)
+ return 1;
+
+ bar = FL_GET_BASE(board->flags);
+ offset += idx * board->uart_offset;
+
+ addr
Re: [alsa-devel] [RFC PATCH 16/40] soundwire: cadence_master: improve startup sequence with link hw_reset
On Thu, Jul 25, 2019 at 06:40:08PM -0500, Pierre-Louis Bossart wrote:
> Enable interrupts first, then engage hardware bus reset with maximum
> duration to make sure the Slave(s) correctly detect the reset pattern
> and to ensure electrical conflicts can be resolved.
>
> Without these changes the initialization is randomly corrupted by bus
> clashes, parity errors and Slave attachment does not generate any
> interrupt, despite the status showing them being attached.
>
> Signed-off-by: Pierre-Louis Bossart
> ---
> drivers/soundwire/cadence_master.c | 35 +-
> 1 file changed, 30 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/soundwire/cadence_master.c
> b/drivers/soundwire/cadence_master.c
> index 25d5c7267c15..442f78c00f09 100644
> --- a/drivers/soundwire/cadence_master.c
> +++ b/drivers/soundwire/cadence_master.c
> @@ -778,6 +778,31 @@ EXPORT_SYMBOL(sdw_cdns_thread);
> * init routines
> */
>
> +static int do_reset(struct sdw_cdns *cdns)
> +{
> + int ret;
> +
> + /* program maximum length reset to be safe */
> + cdns_updatel(cdns, CDNS_MCP_CONTROL,
> + CDNS_MCP_CONTROL_RST_DELAY,
> + CDNS_MCP_CONTROL_RST_DELAY);
> +
> + /* use hardware generated reset */
> + cdns_updatel(cdns, CDNS_MCP_CONTROL,
> + CDNS_MCP_CONTROL_HW_RST,
> + CDNS_MCP_CONTROL_HW_RST);
> +
> + /* enable bus operations with clock and data */
> + cdns_updatel(cdns, CDNS_MCP_CONFIG,
> + CDNS_MCP_CONFIG_OP,
> + CDNS_MCP_CONFIG_OP_NORMAL);
> +
> + /* commit changes */
> + ret = cdns_update_config(cdns);
> +
> + return ret;
+ return cdns_update_config(cdns);
and remove the "ret" variable.
Thanks
Guennadi
> +}
> +
> /**
> * sdw_cdns_enable_interrupt() - Enable SDW interrupts and update config
> * @cdns: Cadence instance
> @@ -809,7 +834,7 @@ int sdw_cdns_enable_interrupt(struct sdw_cdns *cdns)
>
> cdns_writel(cdns, CDNS_MCP_INTMASK, mask);
>
> - return 0;
> + return do_reset(cdns);
> }
> EXPORT_SYMBOL(sdw_cdns_enable_interrupt);
>
> @@ -958,6 +983,10 @@ int sdw_cdns_init(struct sdw_cdns *cdns)
> cdns_writel(cdns, CDNS_MCP_SSP_CTRL0, CDNS_DEFAULT_SSP_INTERVAL);
> cdns_writel(cdns, CDNS_MCP_SSP_CTRL1, CDNS_DEFAULT_SSP_INTERVAL);
>
> + /* flush command FIFOs */
> + cdns_updatel(cdns, CDNS_MCP_CONTROL, CDNS_MCP_CONTROL_CMD_RST,
> + CDNS_MCP_CONTROL_CMD_RST);
> +
> /* Set cmd accept mode */
> cdns_updatel(cdns, CDNS_MCP_CONTROL, CDNS_MCP_CONTROL_CMD_ACCEPT,
>CDNS_MCP_CONTROL_CMD_ACCEPT);
> @@ -980,10 +1009,6 @@ int sdw_cdns_init(struct sdw_cdns *cdns)
> /* Set cmd mode for Tx and Rx cmds */
> val &= ~CDNS_MCP_CONFIG_CMD;
>
> - /* Set operation to normal */
> - val &= ~CDNS_MCP_CONFIG_OP;
> - val |= CDNS_MCP_CONFIG_OP_NORMAL;
> -
> cdns_writel(cdns, CDNS_MCP_CONFIG, val);
>
> /* commit changes */
> --
> 2.20.1
>
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Re: [PATCH 5.1 000/371] 5.1.20-stable review
On Thu, Jul 25, 2019 at 03:19:00PM -0700, Guenter Roeck wrote: > On Wed, Jul 24, 2019 at 09:15:52PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.1.20 release. > > There are 371 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Fri 26 Jul 2019 07:13:35 PM UTC. > > Anything received after that time might be too late. > > > > For v5.1.19-370-gfb6ea525ffcf: > > Build results: > total: 159 pass: 159 fail: 0 > Qemu test results: > total: 364 pass: 364 fail: 0 Wonderful, glad it is all now working. Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On Fri, Jul 26, 2019 at 12:18:54AM -0600, Kelsey Skunberg wrote: > On Wed, Jul 24, 2019 at 09:14:51PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.2.3 release. > > There are 413 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Fri 26 Jul 2019 07:13:35 PM UTC. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.3-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.2.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > Compiled and booted with no regressions on my system. Great, thanks for testing and letting me know. greg k-h
Re: [PATCH 4.19 000/271] 4.19.61-stable review
On Thu, Jul 25, 2019 at 10:14:01AM +0530, Naresh Kamboju wrote: > On Thu, 25 Jul 2019 at 01:35, Greg Kroah-Hartman > wrote: > > > > This is the start of the stable review cycle for the 4.19.61 release. > > There are 271 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Fri 26 Jul 2019 07:13:35 PM UTC. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.61-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.19.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Results from Linaro’s test farm. > No regressions on arm64, arm, x86_64, and i386. > > Summary > > > kernel: 4.19.61-rc1 > git repo: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > git branch: linux-4.19.y > git commit: 872cde3ebfc93ca6ac127f51bbb54eafe1d8eda5 > git describe: v4.19.60-272-g872cde3ebfc9 > Test details: > https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.60-272-g872cde3ebfc9 > > No regressions (compared to build v4.19.60) > > No fixes (compared to build v4.19.60) > > Ran 23544 total tests in the following environments and test suites. Thanks for testing all of tehse and letting me know. greg k-h
Re: [RFC PATCH 00/10] implement KASLR for powerpc/fsl_booke/32
On 2019/7/26 15:04, Diana Madalina Craciun wrote: Hi Jason, I have briefly tested yesterday on a P4080 board and did not see any issues. I do not have much expertise on KASLR, but I will take a look over the code. Hi Diana, thanks. Looking forward to your suggestions. Regards, Diana On 7/25/2019 10:16 AM, Jason Yan wrote: Hi all, any comments? On 2019/7/17 16:06, Jason Yan wrote: This series implements KASLR for powerpc/fsl_booke/32, as a security feature that deters exploit attempts relying on knowledge of the location of kernel internals. Since CONFIG_RELOCATABLE has already supported, what we need to do is map or copy kernel to a proper place and relocate. Freescale Book-E parts expect lowmem to be mapped by fixed TLB entries(TLB1). The TLB1 entries are not suitable to map the kernel directly in a randomized region, so we chose to copy the kernel to a proper place and restart to relocate. Entropy is derived from the banner and timer base, which will change every build and boot. This not so much safe so additionally the bootloader may pass entropy via the /chosen/kaslr-seed node in device tree. We will use the first 512M of the low memory to randomize the kernel image. The memory will be split in 64M zones. We will use the lower 8 bit of the entropy to decide the index of the 64M zone. Then we chose a 16K aligned offset inside the 64M zone to put the kernel in. KERNELBASE |--> 64M <--| | | +---+++---+ | |||kernel|| | +---+++---+ | | |-> offset<-| kimage_vaddr We also check if we will overlap with some areas like the dtb area, the initrd area or the crashkernel area. If we cannot find a proper area, kaslr will be disabled and boot from the original kernel. Jason Yan (10): powerpc: unify definition of M_IF_NEEDED powerpc: move memstart_addr and kernstart_addr to init-common.c powerpc: introduce kimage_vaddr to store the kernel base powerpc/fsl_booke/32: introduce create_tlb_entry() helper powerpc/fsl_booke/32: introduce reloc_kernel_entry() helper powerpc/fsl_booke/32: implement KASLR infrastructure powerpc/fsl_booke/32: randomize the kernel image offset powerpc/fsl_booke/kaslr: clear the original kernel if randomized powerpc/fsl_booke/kaslr: support nokaslr cmdline parameter powerpc/fsl_booke/kaslr: dump out kernel offset information on panic arch/powerpc/Kconfig | 11 + arch/powerpc/include/asm/nohash/mmu-book3e.h | 10 + arch/powerpc/include/asm/page.h | 7 + arch/powerpc/kernel/Makefile | 1 + arch/powerpc/kernel/early_32.c| 2 +- arch/powerpc/kernel/exceptions-64e.S | 10 - arch/powerpc/kernel/fsl_booke_entry_mapping.S | 23 +- arch/powerpc/kernel/head_fsl_booke.S | 61 ++- arch/powerpc/kernel/kaslr_booke.c | 439 ++ arch/powerpc/kernel/machine_kexec.c | 1 + arch/powerpc/kernel/misc_64.S | 5 - arch/powerpc/kernel/setup-common.c| 23 + arch/powerpc/mm/init-common.c | 7 + arch/powerpc/mm/init_32.c | 5 - arch/powerpc/mm/init_64.c | 5 - arch/powerpc/mm/mmu_decl.h| 10 + arch/powerpc/mm/nohash/fsl_booke.c| 8 +- 17 files changed, 580 insertions(+), 48 deletions(-) create mode 100644 arch/powerpc/kernel/kaslr_booke.c .
Re: [PATCH 00/10] make "order" unsigned int
On Fri, Jul 26, 2019 at 02:42:43AM +0800, Pengfei Li wrote: > Objective > > The motivation for this series of patches is use unsigned int for > "order" in compaction.c, just like in other memory subsystems. > Why? The series is relatively subtle in parts, particularly patch 5. There have been places where by it was important for order to be able to go negative due to loop exit conditions. If there was a gain from this or it was a cleanup in the context of another major body of work, I could understand the justification but that does not appear to be the case here. -- Mel Gorman SUSE Labs
Re: [PATCH v6] serial/8250: Add support for NI-Serial PXI/PXIe+485 devices
On Fri, Jul 26, 2019 at 03:22:26PM +0800, jeyentam wrote: > Add support for NI-Serial PXIe-RS232, PXI-RS485 and PXIe-RS485 devices. > > Signed-off-by: Je Yen Tam "From:" name does not match the Signed-off-by: name :(
Re: [PATCH v3 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently
On 19.07.19 02:58, Nadav Amit wrote: To improve TLB shootdown performance, flush the remote and local TLBs concurrently. Introduce flush_tlb_multi() that does so. Introduce paravirtual versions of flush_tlb_multi() for KVM, Xen and hyper-v (Xen and hyper-v are only compile-tested). While the updated smp infrastructure is capable of running a function on a single local core, it is not optimized for this case. The multiple function calls and the indirect branch introduce some overhead, and might make local TLB flushes slower than they were before the recent changes. Before calling the SMP infrastructure, check if only a local TLB flush is needed to restore the lost performance in this common case. This requires to check mm_cpumask() one more time, but unless this mask is updated very frequently, this should impact performance negatively. Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Stephen Hemminger Cc: Sasha Levin Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: x...@kernel.org Cc: Juergen Gross Cc: Paolo Bonzini Cc: Dave Hansen Cc: Andy Lutomirski Cc: Peter Zijlstra Cc: Boris Ostrovsky Cc: linux-hyp...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: virtualizat...@lists.linux-foundation.org Cc: k...@vger.kernel.org Cc: xen-de...@lists.xenproject.org Signed-off-by: Nadav Amit --- arch/x86/hyperv/mmu.c | 10 +++--- arch/x86/include/asm/paravirt.h | 6 ++-- arch/x86/include/asm/paravirt_types.h | 4 +-- arch/x86/include/asm/tlbflush.h | 8 ++--- arch/x86/include/asm/trace/hyperv.h | 2 +- arch/x86/kernel/kvm.c | 11 +-- arch/x86/kernel/paravirt.c| 2 +- arch/x86/mm/tlb.c | 47 ++- arch/x86/xen/mmu_pv.c | 11 +++ include/trace/events/xen.h| 2 +- 10 files changed, 62 insertions(+), 41 deletions(-) Xen and paravirt parts: Reviewed-by: Juergen Gross Juergen
Re: [PATCH] regulator: of: Add of_node_put() before return in function
On 24/07/19 9:17 PM, Mark Brown wrote:
On Wed, Jul 24, 2019 at 02:02:31PM +0530, Nishka Dasgupta wrote:
The local variable search in regulator_of_get_init_node takes the value
returned by either of_get_child_by_name or of_node_get, both of which
get a node. If this node is not put before returning, it could cause a
memory leak. Hence put search before a mid-loop return statement.
Issue found with Coccinelle.
- if (!strcmp(desc->of_match, name))
+ if (!strcmp(desc->of_match, name)) {
+ of_node_put(search);
return of_node_get(child);
+ }
Why not just remove the extra of_node_get() and a comment explaining why
it's not needed?
I'm sorry, I don't think I understand. I'm putting search in this patch;
the program was already getting child. Should I also return child
directly instead of getting it again, and continue to put search?
Thanking you,
Nishka
RE: Re: [PATCH v6] serial/8250: Add support for NI-Serial PXI/PXIe+485 devices
> Subject: [EXTERNAL] Re: [PATCH v6] serial/8250: Add support for NI-Serial > PXI/PXIe+485 devices > > On Fri, Jul 26, 2019 at 03:22:26PM +0800, jeyentam wrote: > > Add support for NI-Serial PXIe-RS232, PXI-RS485 and PXIe-RS485 devices. > > > > Signed-off-by: Je Yen Tam > > "From:" name does not match the Signed-off-by: name :( Change it in v7?
Re: [alsa-devel] [RFC PATCH 17/40] soundwire: bus: use runtime_pm_get_sync/pm when enabled
Hi Pierre,
I might be wrong but this doesn't seem right to me. (Supposedly) all RT-PM
functions check for "enabled" internally. The only thing that can happen is
that if RT-PM isn't enabled some of those functions will return an error.
So, in those cases where the return value of RT-PM functions isn't checked,
I don't think you need to do anything. Where it is checked maybe do
+ if (ret < 0 && pm_runtime_enabled(slave->bus->dev))
Thanks
Guennadi
On Thu, Jul 25, 2019 at 06:40:09PM -0500, Pierre-Louis Bossart wrote:
> Not all platforms support runtime_pm for now, let's use runtime_pm
> only when enabled.
>
> Suggested-by: Srinivas Kandagatla
> Signed-off-by: Pierre-Louis Bossart
> ---
> drivers/soundwire/bus.c | 25 -
> 1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
> index 5ad4109dc72f..0a45dc5713df 100644
> --- a/drivers/soundwire/bus.c
> +++ b/drivers/soundwire/bus.c
> @@ -332,12 +332,16 @@ int sdw_nread(struct sdw_slave *slave, u32 addr, size_t
> count, u8 *val)
> if (ret < 0)
> return ret;
>
> - ret = pm_runtime_get_sync(slave->bus->dev);
> - if (ret < 0)
> - return ret;
> + if (pm_runtime_enabled(slave->bus->dev)) {
> + ret = pm_runtime_get_sync(slave->bus->dev);
> + if (ret < 0)
> + return ret;
> + }
>
> ret = sdw_transfer(slave->bus, );
> - pm_runtime_put(slave->bus->dev);
> +
> + if (pm_runtime_enabled(slave->bus->dev))
> + pm_runtime_put(slave->bus->dev);
>
> return ret;
> }
> @@ -359,13 +363,16 @@ int sdw_nwrite(struct sdw_slave *slave, u32 addr,
> size_t count, u8 *val)
> slave->dev_num, SDW_MSG_FLAG_WRITE, val);
> if (ret < 0)
> return ret;
> -
> - ret = pm_runtime_get_sync(slave->bus->dev);
> - if (ret < 0)
> - return ret;
> + if (pm_runtime_enabled(slave->bus->dev)) {
> + ret = pm_runtime_get_sync(slave->bus->dev);
> + if (ret < 0)
> + return ret;
> + }
>
> ret = sdw_transfer(slave->bus, );
> - pm_runtime_put(slave->bus->dev);
> +
> + if (pm_runtime_enabled(slave->bus->dev))
> + pm_runtime_put(slave->bus->dev);
>
> return ret;
> }
> --
> 2.20.1
>
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
[PATCH v7] serial/8250: Add support for NI-Serial PXI/PXIe+485 devices
Add support for NI-Serial PXIe-RS232, PXI-RS485 and PXIe-RS485 devices.
Signed-off-by: Je Yen Tam
---
v6 -> v7
- Fix sender full name.
v5 -> v6
- Fix author full name.
v4 -> v5
- Remove blank lines between variable definitions.
- Remove trace_printk().
v3 -> v4:
- Add changes description.
v2 -> v3:
- Add "full" name for author
- Use BIT() macro for bits definition
- Remove unnecessary WARN_ON()
- Change debugging interface to ftrace
- Fix indentation
- Add NI PXIe-RS232 and PXI/PXIe-RS485 device IDs #defines
v1 -> v2:
- Fix unintended indentation
v1:
- Add and rename #defines for 16550 UART Port Control Register
- Add configuration for RS485 port.
- Add device setup for NI PXI/PXIe-RS485 family.
- Add PCI board attributes for NI PXIe-RS232 and PXI/PXIe-RS485 devices.
drivers/tty/serial/8250/8250_pci.c | 292 -
1 file changed, 288 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_pci.c
b/drivers/tty/serial/8250/8250_pci.c
index df41397de478..a675069571b2 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -730,8 +730,16 @@ static int pci_ni8430_init(struct pci_dev *dev)
}
/* UART Port Control Register */
-#define NI8430_PORTCON 0x0f
-#define NI8430_PORTCON_TXVR_ENABLE (1 << 3)
+#define NI16550_PCR_OFFSET 0x0f
+#define NI16550_PCR_RS422 0x00
+#define NI16550_PCR_ECHO_RS485 0x01
+#define NI16550_PCR_DTR_RS485 0x02
+#define NI16550_PCR_AUTO_RS485 0x03
+#define NI16550_PCR_WIRE_MODE_MASK 0x03
+#define NI16550_PCR_TXVR_ENABLE_BITBIT(3)
+#define NI16550_PCR_RS485_TERMINATION_BIT BIT(6)
+#define NI16550_ACR_DTR_AUTO_DTR (0x2 << 3)
+#define NI16550_ACR_DTR_MANUAL_DTR (0x0 << 3)
static int
pci_ni8430_setup(struct serial_private *priv,
@@ -753,14 +761,117 @@ pci_ni8430_setup(struct serial_private *priv,
return -ENOMEM;
/* enable the transceiver */
- writeb(readb(p + offset + NI8430_PORTCON) | NI8430_PORTCON_TXVR_ENABLE,
- p + offset + NI8430_PORTCON);
+ writeb(readb(p + offset + NI16550_PCR_OFFSET) |
NI16550_PCR_TXVR_ENABLE_BIT,
+ p + offset + NI16550_PCR_OFFSET);
iounmap(p);
return setup_port(priv, port, bar, offset, board->reg_shift);
}
+static int pci_ni8431_config_rs485(struct uart_port *port,
+ struct serial_rs485 *rs485)
+{
+ u8 pcr, acr;
+ struct uart_8250_port *up;
+
+ up = container_of(port, struct uart_8250_port, port);
+ acr = up->acr;
+ pcr = port->serial_in(port, NI16550_PCR_OFFSET);
+ pcr &= ~NI16550_PCR_WIRE_MODE_MASK;
+
+ if (rs485->flags & SER_RS485_ENABLED) {
+ /* RS-485 */
+ if ((rs485->flags & SER_RS485_RX_DURING_TX) &&
+ (rs485->flags & SER_RS485_RTS_ON_SEND)) {
+ dev_dbg(port->dev, "Invalid 2-wire mode\n");
+ return -EINVAL;
+ }
+
+ if (rs485->flags & SER_RS485_RX_DURING_TX) {
+ /* Echo */
+ dev_vdbg(port->dev, "2-wire DTR with echo\n");
+ pcr |= NI16550_PCR_ECHO_RS485;
+ acr |= NI16550_ACR_DTR_MANUAL_DTR;
+ } else {
+ /* Auto or DTR */
+ if (rs485->flags & SER_RS485_RTS_ON_SEND) {
+ /* Auto */
+ dev_vdbg(port->dev, "2-wire Auto\n");
+ pcr |= NI16550_PCR_AUTO_RS485;
+ acr |= NI16550_ACR_DTR_AUTO_DTR;
+ } else {
+ /* DTR-controlled */
+ /* No Echo */
+ dev_vdbg(port->dev, "2-wire DTR no echo\n");
+ pcr |= NI16550_PCR_DTR_RS485;
+ acr |= NI16550_ACR_DTR_MANUAL_DTR;
+ }
+ }
+ } else {
+ /* RS-422 */
+ dev_vdbg(port->dev, "4-wire\n");
+ pcr |= NI16550_PCR_RS422;
+ acr |= NI16550_ACR_DTR_MANUAL_DTR;
+ }
+
+ dev_dbg(port->dev, "write pcr: 0x%08x\n", pcr);
+ port->serial_out(port, NI16550_PCR_OFFSET, pcr);
+
+ up->acr = acr;
+ port->serial_out(port, UART_SCR, UART_ACR);
+ port->serial_out(port, UART_ICR, up->acr);
+
+ /* Update the cache. */
+ port->rs485 = *rs485;
+
+ return 0;
+}
+
+static int pci_ni8431_setup(struct serial_private *priv,
+const struct pciserial_board *board,
+struct uart_8250_port *uart, int idx)
+{
+ u8 pcr, acr;
+ struct pci_dev *dev = priv->dev;
+ void __iomem *addr;
+ unsigned int bar, offset = board->first_offset;
+
+ if (idx >= board->num_ports)
+ return 1;
+
+ bar = FL_GET_BASE(board->flags);
+ offset += idx *
Re: [PATCH 1/1] x86/boot: clear some fields explicitly
On Thu, 25 Jul 2019, John Hubbard wrote:
> On 7/25/19 3:28 PM, H. Peter Anvin wrote:
> > On 7/25/19 3:03 PM, Thomas Gleixner wrote:
> >> On Thu, 25 Jul 2019, h...@zytor.com wrote:
> >>> On July 25, 2019 2:48:30 PM PDT, Thomas Gleixner
> >>> wrote:
>
> But seriously I think it's not completely insane what they are doing
> and the table based approach is definitely more readable and maintainable
> than the existing stuff.
> >>>
> >>> Doing this table based does seem like a good idea.
> >>
> >> The question is whether we use a 'toclear' table or a 'preserve' table. I'd
> >> argue that the 'preserve' approach is saner.
> >>
> >
> > I agree.
> >
>
> OK, I can polish up something and post it, if you can help me with one more
> quick question: how did you want "to preserve" to work?
>
> a) copy out fields to preserve, memset the area to zero, copy back preserved
> fields? This seems like it would have the same gcc warnings as we have now,
> due to the requirement to memset a range of a struct...
Use the same trick I used for the toclear variant.
#define PRESERVE(m) \
{ \
.start = offsetof(m), \
.len = sizeof(m), \
}
sanitize_boot_params(bp, scratch)
{
char *p1 = bp, *p2 = scratch;
preserve[] = {
PRESERVE(member1),
...
PRESERVE(memberN),
};
for_each_preserve(pr)
memcpy(p2 + pr->start, p1 + pr->start, pr->len)
memcpy(bp, scratch, ...);
}
Thanks,
tglx
Re: [PATCH RESEND] autonuma: Fix scan period updating
Hi, Srikar,
Srikar Dronamraju writes:
> * Huang, Ying [2019-07-25 16:01:24]:
>
>> From: Huang Ying
>>
>> From the commit log and comments of commit 37ec97deb3a8 ("sched/numa:
>> Slow down scan rate if shared faults dominate"), the autonuma scan
>> period should be increased (scanning is slowed down) if the majority
>> of the page accesses are shared with other processes. But in current
>> code, the scan period will be decreased (scanning is speeded up) in
>> that situation.
>>
>> The commit log and comments make more sense. So this patch fixes the
>> code to make it match the commit log and comments. And this has been
>> verified via tracing the scan period changing and /proc/vmstat
>> numa_pte_updates counter when running a multi-threaded memory
>> accessing program (most memory areas are accessed by multiple
>> threads).
>>
>
> Lets split into 4 modes.
> More Local and Private Page Accesses:
> We definitely want to scan slowly i.e increase the scan window.
>
> More Local and Shared Page Accesses:
> We still want to scan slowly because we have consolidated and there is no
> point in scanning faster. So scan slowly + increase the scan window.
> (Do remember access on any active node counts as local!!!)
>
> More Remote + Private page Accesses:
> Most likely the Private accesses are going to be local accesses.
>
> In the unlikely event of the private accesses not being local, we should
> scan faster so that the memory and task consolidates.
>
> More Remote + Shared page Accesses: This means the workload has not
> consolidated and needs to scan faster. So we need to scan faster.
This sounds reasonable. But
lr_ratio < NUMA_PERIOD_THRESHOLD
doesn't indicate More Remote. If Local = Remote, it is also true. If
there are also more Shared, we should slow down the scanning. So, the
logic could be
if (lr_ratio >= NUMA_PERIOD_THRESHOLD)
slow down scanning
else if (sp_ratio >= NUMA_PERIOD_THRESHOLD) {
if (NUMA_PERIOD_SLOTS - lr_ratio >= NUMA_PERIOD_THRESHOLD)
speed up scanning
else
slow down scanning
} else
speed up scanning
This follows your idea better?
Best Regards,
Huang, Ying
> So I would think we should go back to before 37ec97deb3a8.
>
> i.e
>
> int slot = lr_ratio - NUMA_PERIOD_THRESHOLD;
>
> if (!slot)
> slot = 1;
> diff = slot * period_slot;
>
>
> No?
>
>> Fixes: 37ec97deb3a8 ("sched/numa: Slow down scan rate if shared faults
>> dominate")
>> Signed-off-by: "Huang, Ying"
>> Cc: Rik van Riel
>> Cc: Peter Zijlstra (Intel)
>> Cc: Mel Gorman
>> Cc: jhla...@redhat.com
>> Cc: lvena...@redhat.com
>> Cc: Ingo Molnar
>> Cc: Andrew Morton
>> ---
>> kernel/sched/fair.c | 20 ++--
>> 1 file changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 036be95a87e9..468a1c5038b2 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -1940,7 +1940,7 @@ static void update_task_scan_period(struct task_struct
>> *p,
>> unsigned long shared, unsigned long private)
>> {
>> unsigned int period_slot;
>> -int lr_ratio, ps_ratio;
>> +int lr_ratio, sp_ratio;
>> int diff;
>>
>> unsigned long remote = p->numa_faults_locality[0];
>> @@ -1971,22 +1971,22 @@ static void update_task_scan_period(struct
>> task_struct *p,
>> */
>> period_slot = DIV_ROUND_UP(p->numa_scan_period, NUMA_PERIOD_SLOTS);
>> lr_ratio = (local * NUMA_PERIOD_SLOTS) / (local + remote);
>> -ps_ratio = (private * NUMA_PERIOD_SLOTS) / (private + shared);
>> +sp_ratio = (shared * NUMA_PERIOD_SLOTS) / (private + shared);
>>
>> -if (ps_ratio >= NUMA_PERIOD_THRESHOLD) {
>> +if (sp_ratio >= NUMA_PERIOD_THRESHOLD) {
>> /*
>> - * Most memory accesses are local. There is no need to
>> - * do fast NUMA scanning, since memory is already local.
>> + * Most memory accesses are shared with other tasks.
>> + * There is no point in continuing fast NUMA scanning,
>> + * since other tasks may just move the memory elsewhere.
>
> With this change, I would expect that with Shared page accesses,
> consolidation to take a hit.
>
>> */
>> -int slot = ps_ratio - NUMA_PERIOD_THRESHOLD;
>> +int slot = sp_ratio - NUMA_PERIOD_THRESHOLD;
>> if (!slot)
>> slot = 1;
>> diff = slot * period_slot;
>> } else if (lr_ratio >= NUMA_PERIOD_THRESHOLD) {
>> /*
>> - * Most memory accesses are shared with other tasks.
>> - * There is no point in continuing fast NUMA scanning,
>> - * since other tasks may just move the memory elsewhere.
>> + * Most memory accesses are local. There is no need to
>> + * do fast NUMA scanning, since memory is already local.
>
> Comment wise this make sense.
>
>> */
>>
[iommu/dma] b1d2dc009d: can't load the disk
FYI, we noticed the following commit (built with gcc-7):
commit: 1b961423158caaae49d3900b7c9c37477bbfa9b3 ("iommu/dma: Fix condition check in
iommu_dma_unmap_sg")
https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git
master
on test machine: Intel(R) Xeon(R) CPU E7-8890 v3 @ 2.50GHz with 512G memory
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
If you fix the issue, kindly add following tag
Reported-by: kernel test robot
Starting Login Service...
Starting LKP bootstrap...
Starting Permit User Sessions...
Starting LSB: Execute the kexec -e command to reboot system...
Starting OpenBSD Secure Shell server...
LKP: HOSTNAME lkp-hsw-4ex1, MAC a0:36:9f:18:d6:a8, kernel
5.2.0-rc2-00025-gb1d2dc0 1, serial console /dev/ttyS0
Starting LSB: Start and stop bmc-watchdog...
Starting /etc/rc.local Compatibility...
[ 36.033591] rc.local[1472]: mkdir: cannot create directory '/var/lock/lkp-boo
[ 40.218548] mgag200 :08:00.0: VGA-1: EDID is invalid:
tstrap.lock': Fi
[ 40.219847] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 40.225126] [00] BAD 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
[ 40.225127] [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
le exists
[ 40.225127] [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 40.225128] [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 40.225131] [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 40.235427] ata5.00: ATAPI: TEACDV-W28S-W, 1.0A, max UDMA/100
[ 40.240884] [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 40.240885] [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 40.240885] [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 40.299838] fbcon: mgag200drmfb (fb0) is primary device
[ 40.299956] Console: switching to colour frame buffer device 128x48
[ 40.301806] ata5.00: configured for UDMA/100
[ 40.306906] scsi 5:0:0:0: CD-ROMTEAC DV-W28S-W1.0A
PQ: 0 ANSI: 5
[ 40.308685] EDAC sbridge: Seeking for: PCI ID 8086:2fa0
[ 40.308711] EDAC sbridge: Seeking for: PCI ID 8086:2fa0
[ 40.308749] EDAC sbridge: Seeking for: PCI ID 8086:2fa0
[ 40.308784] EDAC sbridge: Seeking for: PCI ID 8086:2fa0
[ 40.308820] EDAC sbridge: Seeking for: PCI ID 8086:2fa0
[ 40.308855] EDAC sbridge: Seeking for: PCI ID 8086:2f60
[ 40.308862] EDAC sbridge: Seeking for: PCI ID 8086:2f60
[ 40.308876] EDAC sbridge: Seeking for: PCI ID 8086:2f60
[ 40.30] EDAC sbridge: Seeking for: PCI ID 8086:2f60
[ 40.308901] EDAC sbridge: Seeking for: PCI ID 8086:2f60
[ 40.308911] EDAC sbridge: Seeking for: PCI ID 8086:2fa8
[ 40.308918] EDAC sbridge: Seeking for: PCI ID 8086:2fa8
[ 40.308930] EDAC sbridge: Seeking for: PCI ID 8086:2fa8
[ 40.308941] EDAC sbridge: Seeking for: PCI ID 8086:2fa8
[ 40.308952] EDAC sbridge: Seeking for: PCI ID 8086:2fa8
[ 40.308962] EDAC sbridge: Seeking for: PCI ID 8086:2f71
[ 40.308969] EDAC sbridge: Seeking for: PCI ID 8086:2f71
[ 40.308980] EDAC sbridge: Seeking for: PCI ID 8086:2f71
[ 40.308991] EDAC sbridge: Seeking for: PCI ID 8086:2f71
[ 40.309005] EDAC sbridge: Seeking for: PCI ID 8086:2f71
[ 40.309016] EDAC sbridge: Seeking for: PCI ID 8086:2faa
[ 40.309023] EDAC sbridge: Seeking for: PCI ID 8086:2faa
[ 40.309036] EDAC sbridge: Seeking for: PCI ID 8086:2faa
[ 40.309048] EDAC sbridge: Seeking for: PCI ID 8086:2faa
[ 40.309062] EDAC sbridge: Seeking for: PCI ID 8086:2faa
[ 40.309073] EDAC sbridge: Seeking for: PCI ID 8086:2fab
[ 40.309082] EDAC sbridge: Seeking for: PCI ID 8086:2fab
[ 40.309116] EDAC sbridge: Seeking for: PCI ID 8086:2fab
[ 40.309128] EDAC sbridge: Seeking for: PCI ID 8086:2fab
[ 40.309141] EDAC sbridge: Seeking for: PCI ID 8086:2fab
[ 40.309151] EDAC sbridge: Seeking for: PCI ID 8086:2fac
[ 40.309159] EDAC sbridge: Seeking for: PCI ID 8086:2fac
iommu/dma
[ 40.309172] EDAC sbridge: Seeking for: PCI ID 8086:2fac
[ 40.309184] EDAC sbridge: Seeking for: PCI ID 8086:2fac
[ 40.309197] EDAC sbridge: Seeking for: PCI ID 8086:2fac
[ 40.309207] EDAC sbridge: Seeking for: PCI ID 8086:2fad
[ 40.309215] EDAC sbridge: Seeking for: PCI ID 8086:2fad
[ 40.309227] EDAC sbridge: Seeking for: PCI ID 8086:2fad
[ 40.309239] EDAC sbridge: Seeking for: PCI ID 8086:2fad
[ 40.309251] EDAC sbridge: Seeking for: PCI ID 8086:2fad
[ 40.309261] EDAC sbridge: Seeking for: PCI ID 8086:2f68
[ 40.309271] EDAC sbridge: Seeking for: PCI ID 8086:2f68
[ 40.309283] EDAC sbridge: Seeking for: PCI ID 8086:2f68
[ 40.309296] EDAC sbridge: Seeking for: PCI ID 8086:2f68
[ 40.309314] EDAC sbridge: Seeking for: PCI ID 8086:2f68
[ 40.309322] EDAC sbridge: Seeking for: PCI ID 8086:2f79
[ 40.309332] EDAC sbridge: Seeking for: PCI ID 8086:2f79
[ 40.309344] EDAC sbridge: Seeking for: PCI ID 8086:2f79
[ 40.309357] EDAC sbridge: Seeking for:
Re: [PATCH] KVM: X86: Use IPI shorthands in kvm guest when support
On Fri, 26 Jul 2019 at 15:20, Thomas Gleixner wrote:
>
> On Fri, 26 Jul 2019, Wanpeng Li wrote:
> > On Fri, 26 Jul 2019 at 14:10, Wanpeng Li wrote:
> > > static void kvm_send_ipi_all(int vector)
> > > {
> > > - __send_ipi_mask(cpu_online_mask, vector);
> > > + if (static_branch_likely(_use_ipi_shorthand))
> > > + orig_apic.send_IPI_allbutself(vector);
> >
> > Make a mistake here, just resend the patch.
>
> Please don't use [RESEND] if the patch is different. Use [PATCH v2].
>
> [RESEND] is used when you actually resend an unmodified patch, e.g. when
> the first submission was ignored for a longer time.
Will do for next time, I guess Paolo can still review the [RESEND] one
for this time to avoid my patch flush the mailing list. :)
Regards,
Wanpeng Li
Re: [alsa-devel] [RFC PATCH 17/40] soundwire: bus: use runtime_pm_get_sync/pm when enabled
Hello,
I while back I proposed a patch for this, but it went nowhere.
https://patchwork.kernel.org/patch/10887405/
Maybe something similar can be implemented?
Jan
> On 26 Jul 2019, at 09:39, Guennadi Liakhovetski
> wrote:
>
> EXTERNAL MAIL
>
>
> Hi Pierre,
>
> I might be wrong but this doesn't seem right to me. (Supposedly) all RT-PM
> functions check for "enabled" internally. The only thing that can happen is
> that if RT-PM isn't enabled some of those functions will return an error.
> So, in those cases where the return value of RT-PM functions isn't checked,
> I don't think you need to do anything. Where it is checked maybe do
>
> + if (ret < 0 && pm_runtime_enabled(slave->bus->dev))
>
> Thanks
> Guennadi
>
> On Thu, Jul 25, 2019 at 06:40:09PM -0500, Pierre-Louis Bossart wrote:
>> Not all platforms support runtime_pm for now, let's use runtime_pm
>> only when enabled.
>>
>> Suggested-by: Srinivas Kandagatla
>> Signed-off-by: Pierre-Louis Bossart
>> ---
>> drivers/soundwire/bus.c | 25 -
>> 1 file changed, 16 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
>> index 5ad4109dc72f..0a45dc5713df 100644
>> --- a/drivers/soundwire/bus.c
>> +++ b/drivers/soundwire/bus.c
>> @@ -332,12 +332,16 @@ int sdw_nread(struct sdw_slave *slave, u32 addr,
>> size_t count, u8 *val)
>> if (ret < 0)
>> return ret;
>>
>> -ret = pm_runtime_get_sync(slave->bus->dev);
>> -if (ret < 0)
>> -return ret;
>> +if (pm_runtime_enabled(slave->bus->dev)) {
>> +ret = pm_runtime_get_sync(slave->bus->dev);
>> +if (ret < 0)
>> +return ret;
>> +}
>>
>> ret = sdw_transfer(slave->bus, );
>> -pm_runtime_put(slave->bus->dev);
>> +
>> +if (pm_runtime_enabled(slave->bus->dev))
>> +pm_runtime_put(slave->bus->dev);
>>
>> return ret;
>> }
>> @@ -359,13 +363,16 @@ int sdw_nwrite(struct sdw_slave *slave, u32 addr,
>> size_t count, u8 *val)
>> slave->dev_num, SDW_MSG_FLAG_WRITE, val);
>> if (ret < 0)
>> return ret;
>> -
>> -ret = pm_runtime_get_sync(slave->bus->dev);
>> -if (ret < 0)
>> -return ret;
>> +if (pm_runtime_enabled(slave->bus->dev)) {
>> +ret = pm_runtime_get_sync(slave->bus->dev);
>> +if (ret < 0)
>> +return ret;
>> +}
>>
>> ret = sdw_transfer(slave->bus, );
>> -pm_runtime_put(slave->bus->dev);
>> +
>> +if (pm_runtime_enabled(slave->bus->dev))
>> +pm_runtime_put(slave->bus->dev);
>>
>> return ret;
>> }
>> --
>> 2.20.1
>>
>> ___
>> Alsa-devel mailing list
>> alsa-de...@alsa-project.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.alsa-2Dproject.org_mailman_listinfo_alsa-2Ddevel=DwIBAg=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3GZ-_haXqY=g7GAQENVXx_RQdyXHInPMg=vETGQLSPeGb7K_ZsXv4Tl3VFfdXzyummTDga97ozJcg=LiW4SToh5U0zhnkox54oRhJ1u3vFNbBB9nmzRDuCDjI=
[PATCH] fs: nfs: Fix possible null-pointer dereferences in encode_attrs()
In encode_attrs(), there is an if statement on line 1145 to check
whether label is NULL:
if (label && (attrmask[2] & FATTR4_WORD2_SECURITY_LABEL))
When label is NULL, it is used on lines 1178-1181:
*p++ = cpu_to_be32(label->lfs);
*p++ = cpu_to_be32(label->pi);
*p++ = cpu_to_be32(label->len);
p = xdr_encode_opaque_fixed(p, label->label, label->len);
To fix these bugs, label is checked before being used.
These bugs are found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai
---
fs/nfs/nfs4xdr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c
index 46a8d636d151..ab07db0f07cd 100644
--- a/fs/nfs/nfs4xdr.c
+++ b/fs/nfs/nfs4xdr.c
@@ -1174,7 +1174,7 @@ static void encode_attrs(struct xdr_stream *xdr, const
struct iattr *iap,
} else
*p++ = cpu_to_be32(NFS4_SET_TO_SERVER_TIME);
}
- if (bmval[2] & FATTR4_WORD2_SECURITY_LABEL) {
+ if (label && (bmval[2] & FATTR4_WORD2_SECURITY_LABEL)) {
*p++ = cpu_to_be32(label->lfs);
*p++ = cpu_to_be32(label->pi);
*p++ = cpu_to_be32(label->len);
--
2.17.0
[PATCH V2 net-next 07/10] net: hns3: make hclge_service use delayed workqueue
From: Yunsheng Lin
Use delayed work instead of using timers to trigger the
hclge_serive.
Simplify the code with one less middle function and in order
to support misc irq affinity.
Signed-off-by: Yunsheng Lin
Reviewed-by: Peng Li
Signed-off-by: Huazhong Tan
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 52 +-
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 3 +-
2 files changed, 21 insertions(+), 34 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 14199c4..13c9697 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -2513,8 +2513,12 @@ static void hclge_task_schedule(struct hclge_dev *hdev)
{
if (!test_bit(HCLGE_STATE_DOWN, >state) &&
!test_bit(HCLGE_STATE_REMOVING, >state) &&
- !test_and_set_bit(HCLGE_STATE_SERVICE_SCHED, >state))
- (void)schedule_work(>service_task);
+ !test_and_set_bit(HCLGE_STATE_SERVICE_SCHED, >state)) {
+ hdev->hw_stats.stats_timer++;
+ hdev->fd_arfs_expire_timer++;
+ mod_delayed_work(system_wq, >service_task,
+round_jiffies_relative(HZ));
+ }
}
static int hclge_get_mac_link_status(struct hclge_dev *hdev)
@@ -2729,25 +2733,6 @@ static int hclge_get_status(struct hnae3_handle *handle)
return hdev->hw.mac.link;
}
-static void hclge_service_timer(struct timer_list *t)
-{
- struct hclge_dev *hdev = from_timer(hdev, t, service_timer);
-
- mod_timer(>service_timer, jiffies + HZ);
- hdev->hw_stats.stats_timer++;
- hdev->fd_arfs_expire_timer++;
- hclge_task_schedule(hdev);
-}
-
-static void hclge_service_complete(struct hclge_dev *hdev)
-{
- WARN_ON(!test_bit(HCLGE_STATE_SERVICE_SCHED, >state));
-
- /* Flush memory before next watchdog */
- smp_mb__before_atomic();
- clear_bit(HCLGE_STATE_SERVICE_SCHED, >state);
-}
-
static u32 hclge_check_event_cause(struct hclge_dev *hdev, u32 *clearval)
{
u32 rst_src_reg, cmdq_src_reg, msix_src_reg;
@@ -3594,7 +3579,9 @@ static void hclge_update_vport_alive(struct hclge_dev
*hdev)
static void hclge_service_task(struct work_struct *work)
{
struct hclge_dev *hdev =
- container_of(work, struct hclge_dev, service_task);
+ container_of(work, struct hclge_dev, service_task.work);
+
+ clear_bit(HCLGE_STATE_SERVICE_SCHED, >state);
if (hdev->hw_stats.stats_timer >= HCLGE_STATS_TIMER_INTERVAL) {
hclge_update_stats_for_all(hdev);
@@ -3609,7 +3596,8 @@ static void hclge_service_task(struct work_struct *work)
hclge_rfs_filter_expire(hdev);
hdev->fd_arfs_expire_timer = 0;
}
- hclge_service_complete(hdev);
+
+ hclge_task_schedule(hdev);
}
struct hclge_vport *hclge_get_vport(struct hnae3_handle *handle)
@@ -6148,10 +6136,13 @@ static void hclge_set_timer_task(struct hnae3_handle
*handle, bool enable)
struct hclge_dev *hdev = vport->back;
if (enable) {
- mod_timer(>service_timer, jiffies + HZ);
+ hclge_task_schedule(hdev);
} else {
- del_timer_sync(>service_timer);
- cancel_work_sync(>service_task);
+ /* Set the DOWN flag here to disable the service to be
+* scheduled again
+*/
+ set_bit(HCLGE_STATE_DOWN, >state);
+ cancel_delayed_work_sync(>service_task);
clear_bit(HCLGE_STATE_SERVICE_SCHED, >state);
}
}
@@ -8590,12 +8581,10 @@ static void hclge_state_uninit(struct hclge_dev *hdev)
set_bit(HCLGE_STATE_DOWN, >state);
set_bit(HCLGE_STATE_REMOVING, >state);
- if (hdev->service_timer.function)
- del_timer_sync(>service_timer);
if (hdev->reset_timer.function)
del_timer_sync(>reset_timer);
- if (hdev->service_task.func)
- cancel_work_sync(>service_task);
+ if (hdev->service_task.work.func)
+ cancel_delayed_work_sync(>service_task);
if (hdev->rst_service_task.func)
cancel_work_sync(>rst_service_task);
if (hdev->mbx_service_task.func)
@@ -8800,9 +8789,8 @@ static int hclge_init_ae_dev(struct hnae3_ae_dev *ae_dev)
hclge_dcb_ops_set(hdev);
- timer_setup(>service_timer, hclge_service_timer, 0);
timer_setup(>reset_timer, hclge_reset_timer, 0);
- INIT_WORK(>service_task, hclge_service_task);
+ INIT_DELAYED_WORK(>service_task, hclge_service_task);
INIT_WORK(>rst_service_task, hclge_reset_service_task);
INIT_WORK(>mbx_service_task, hclge_mailbox_service_task);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
[PATCH V2 net-next 01/10] net: hns3: add reset checking before set channels
From: Jian Shen hns3_set_channels() should check the resetting status firstly, since the device will reinitialize when resetting. If the reset has not completed, the hns3_set_channels() may access invalid memory. Signed-off-by: Jian Shen Signed-off-by: Huazhong Tan --- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c index 69f7ef8..08af782 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c @@ -4378,6 +4378,9 @@ int hns3_set_channels(struct net_device *netdev, u16 org_tqp_num; int ret; + if (hns3_nic_resetting(netdev)) + return -EBUSY; + if (ch->rx_count || ch->tx_count) return -EINVAL; -- 2.7.4
[PATCH V2 net-next 10/10] net: hns3: use dev_info() instead of pr_info()
dev_info() is more appropriate for printing messages when driver
initialization done, so switch to dev_info().
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 4 +++-
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 3 ++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 30a7074..4138780 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -8862,7 +8862,9 @@ static int hclge_init_ae_dev(struct hnae3_ae_dev *ae_dev)
hclge_state_init(hdev);
hdev->last_reset_time = jiffies;
- pr_info("%s driver initialization finished.\n", HCLGE_DRIVER_NAME);
+ dev_info(>pdev->dev, "%s driver initialization finished.\n",
+HCLGE_DRIVER_NAME);
+
return 0;
err_mdiobus_unreg:
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index a13a0e1..ae0e6a6 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -2695,7 +2695,8 @@ static int hclgevf_init_hdev(struct hclgevf_dev *hdev)
}
hdev->last_reset_time = jiffies;
- pr_info("finished initializing %s driver\n", HCLGEVF_DRIVER_NAME);
+ dev_info(>pdev->dev, "finished initializing %s driver\n",
+HCLGEVF_DRIVER_NAME);
return 0;
--
2.7.4
[PATCH V2 net-next 02/10] net: hns3: add a check for get_reset_level
From: Guangbin Huang
For some cases, ops->get_reset_level may not be implemented, so we
should check whether it is NULL before calling get_reset_level.
Signed-off-by: Guangbin Huang
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 08af782..4d58c53 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1963,7 +1963,7 @@ static pci_ers_result_t hns3_slot_reset(struct pci_dev
*pdev)
ops = ae_dev->ops;
/* request the reset */
- if (ops->reset_event) {
+ if (ops->reset_event && ops->get_reset_level) {
if (ae_dev->hw_err_reset_req) {
reset_type = ops->get_reset_level(ae_dev,
_dev->hw_err_reset_req);
--
2.7.4
[PATCH V2 net-next 00/10] net: hns3: some code optimizations & bugfixes & features
This patch-set includes code optimizations, bugfixes and features for the HNS3 ethernet controller driver. [patch 1/10] checks reset status before setting channel. [patch 2/10] adds a NULL pointer checking. [patch 3/10] removes reset level upgrading when current reset fails. [patch 4/10] fixes a GFP flags errors when holding spin_lock. [patch 5/10] modifies firmware version format. [patch 6/10] adds some print information which is off by default. [patch 7/10 - 8/10] adds two code optimizations about interrupt handler and work task. [patch 9/10] adds support for using order 1 pages with a 4K buffer. [patch 10/10] modifies messages prints with dev_info() instead of pr_info(). Change log: V1->V2: fixes comments from Saeed Mahameed and removes previous [patch 4/11] and [patch 11/11] which needs further discussion, and adds a new patch [11/11] suggested by Saeed Mahameed. Guangbin Huang (1): net: hns3: add a check for get_reset_level Huazhong Tan (2): net: hns3: remove upgrade reset level when reset fail net: hns3: use dev_info() instead of pr_info() Jian Shen (1): net: hns3: add reset checking before set channels Yonglong Liu (1): net: hns3: adds debug messages to identify eth down cause Yufeng Mo (2): net: hns3: change GFP flag during lock period net: hns3: modify firmware version display format Yunsheng Lin (3): net: hns3: make hclge_service use delayed workqueue net: hns3: add interrupt affinity support for misc interrupt net: hns3: Add support for using order 1 pages with a 4K buffer drivers/net/ethernet/hisilicon/hns3/hnae3.h| 9 ++ drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 39 +- drivers/net/ethernet/hisilicon/hns3/hns3_enet.h| 15 ++- drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 41 ++- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 10 +- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 14 +++ .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 135 - .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 7 +- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 10 +- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 3 +- 10 files changed, 211 insertions(+), 72 deletions(-) -- 2.7.4
[PATCH V2 net-next 05/10] net: hns3: modify firmware version display format
From: Yufeng Mo
This patch modifies firmware version display format in
hclge(vf)_cmd_init() and hns3_get_drvinfo(). Also, adds
some optimizations for firmware version display format.
Signed-off-by: Yufeng Mo
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 9 +
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 15 +--
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 10 +-
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 10 +-
4 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 48c7b70..a4624db 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -179,6 +179,15 @@ struct hnae3_vector_info {
#define HNAE3_RING_GL_RX 0
#define HNAE3_RING_GL_TX 1
+#define HNAE3_FW_VERSION_BYTE3_SHIFT 24
+#define HNAE3_FW_VERSION_BYTE3_MASKGENMASK(31, 24)
+#define HNAE3_FW_VERSION_BYTE2_SHIFT 16
+#define HNAE3_FW_VERSION_BYTE2_MASKGENMASK(23, 16)
+#define HNAE3_FW_VERSION_BYTE1_SHIFT 8
+#define HNAE3_FW_VERSION_BYTE1_MASKGENMASK(15, 8)
+#define HNAE3_FW_VERSION_BYTE0_SHIFT 0
+#define HNAE3_FW_VERSION_BYTE0_MASKGENMASK(7, 0)
+
struct hnae3_ring_chain_node {
struct hnae3_ring_chain_node *next;
u32 tqp_index;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index 5bff98a..e71c92b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -527,6 +527,7 @@ static void hns3_get_drvinfo(struct net_device *netdev,
{
struct hns3_nic_priv *priv = netdev_priv(netdev);
struct hnae3_handle *h = priv->ae_handle;
+ u32 fw_version;
if (!h->ae_algo->ops->get_fw_version) {
netdev_err(netdev, "could not get fw version!\n");
@@ -545,8 +546,18 @@ static void hns3_get_drvinfo(struct net_device *netdev,
sizeof(drvinfo->bus_info));
drvinfo->bus_info[ETHTOOL_BUSINFO_LEN - 1] = '\0';
- snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version), "0x%08x",
-priv->ae_handle->ae_algo->ops->get_fw_version(h));
+ fw_version = priv->ae_handle->ae_algo->ops->get_fw_version(h);
+
+ snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version),
+"%lu.%lu.%lu.%lu",
+hnae3_get_field(fw_version, HNAE3_FW_VERSION_BYTE3_MASK,
+HNAE3_FW_VERSION_BYTE3_SHIFT),
+hnae3_get_field(fw_version, HNAE3_FW_VERSION_BYTE2_MASK,
+HNAE3_FW_VERSION_BYTE2_SHIFT),
+hnae3_get_field(fw_version, HNAE3_FW_VERSION_BYTE1_MASK,
+HNAE3_FW_VERSION_BYTE1_SHIFT),
+hnae3_get_field(fw_version, HNAE3_FW_VERSION_BYTE0_MASK,
+HNAE3_FW_VERSION_BYTE0_SHIFT));
}
static u32 hns3_get_link(struct net_device *netdev)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
index 22f6acd..d9858f2 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
@@ -419,7 +419,15 @@ int hclge_cmd_init(struct hclge_dev *hdev)
}
hdev->fw_version = version;
- dev_info(>pdev->dev, "The firmware version is %08x\n", version);
+ dev_info(>pdev->dev, "The firmware version is %lu.%lu.%lu.%lu\n",
+hnae3_get_field(version, HNAE3_FW_VERSION_BYTE3_MASK,
+HNAE3_FW_VERSION_BYTE3_SHIFT),
+hnae3_get_field(version, HNAE3_FW_VERSION_BYTE2_MASK,
+HNAE3_FW_VERSION_BYTE2_SHIFT),
+hnae3_get_field(version, HNAE3_FW_VERSION_BYTE1_MASK,
+HNAE3_FW_VERSION_BYTE1_SHIFT),
+hnae3_get_field(version, HNAE3_FW_VERSION_BYTE0_MASK,
+HNAE3_FW_VERSION_BYTE0_SHIFT));
return 0;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
index 652b796..8f21eb3 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
@@ -405,7 +405,15 @@ int hclgevf_cmd_init(struct hclgevf_dev *hdev)
}
hdev->fw_version = version;
- dev_info(>pdev->dev, "The firmware version is %08x\n", version);
+ dev_info(>pdev->dev, "The firmware version is %lu.%lu.%lu.%lu\n",
+hnae3_get_field(version, HNAE3_FW_VERSION_BYTE3_MASK,
+HNAE3_FW_VERSION_BYTE3_SHIFT),
+hnae3_get_field(version,
[PATCH V2 net-next 08/10] net: hns3: add interrupt affinity support for misc interrupt
From: Yunsheng Lin
The misc interrupt is used to schedule the reset and mailbox
subtask, and service_task delayed_work is used to do periodic
management work each second.
This patch sets the above three subtask's affinity using the
misc interrupt' affinity.
Also this patch setups a affinity notify for misc interrupt to
allow user to change the above three subtask's affinity.
Signed-off-by: Yunsheng Lin
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 53 --
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 4 ++
2 files changed, 53 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 13c9697..30a7074 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -1270,6 +1270,12 @@ static int hclge_configure(struct hclge_dev *hdev)
hclge_init_kdump_kernel_config(hdev);
+ /* Set the init affinity based on pci func number */
+ i = cpumask_weight(cpumask_of_node(dev_to_node(>pdev->dev)));
+ i = i ? PCI_FUNC(hdev->pdev->devfn) % i : 0;
+ cpumask_set_cpu(cpumask_local_spread(i, dev_to_node(>pdev->dev)),
+ >affinity_mask);
+
return ret;
}
@@ -2499,14 +2505,16 @@ static void hclge_mbx_task_schedule(struct hclge_dev
*hdev)
{
if (!test_bit(HCLGE_STATE_CMD_DISABLE, >state) &&
!test_and_set_bit(HCLGE_STATE_MBX_SERVICE_SCHED, >state))
- schedule_work(>mbx_service_task);
+ queue_work_on(cpumask_first(>affinity_mask), system_wq,
+ >mbx_service_task);
}
static void hclge_reset_task_schedule(struct hclge_dev *hdev)
{
if (!test_bit(HCLGE_STATE_REMOVING, >state) &&
!test_and_set_bit(HCLGE_STATE_RST_SERVICE_SCHED, >state))
- schedule_work(>rst_service_task);
+ queue_work_on(cpumask_first(>affinity_mask), system_wq,
+ >rst_service_task);
}
static void hclge_task_schedule(struct hclge_dev *hdev)
@@ -2516,8 +2524,9 @@ static void hclge_task_schedule(struct hclge_dev *hdev)
!test_and_set_bit(HCLGE_STATE_SERVICE_SCHED, >state)) {
hdev->hw_stats.stats_timer++;
hdev->fd_arfs_expire_timer++;
- mod_delayed_work(system_wq, >service_task,
-round_jiffies_relative(HZ));
+ mod_delayed_work_on(cpumask_first(>affinity_mask),
+ system_wq, >service_task,
+ round_jiffies_relative(HZ));
}
}
@@ -2903,6 +2912,36 @@ static void hclge_get_misc_vector(struct hclge_dev *hdev)
hdev->num_msi_used += 1;
}
+static void hclge_irq_affinity_notify(struct irq_affinity_notify *notify,
+ const cpumask_t *mask)
+{
+ struct hclge_dev *hdev = container_of(notify, struct hclge_dev,
+ affinity_notify);
+
+ cpumask_copy(>affinity_mask, mask);
+}
+
+static void hclge_irq_affinity_release(struct kref *ref)
+{
+}
+
+static void hclge_misc_affinity_setup(struct hclge_dev *hdev)
+{
+ irq_set_affinity_hint(hdev->misc_vector.vector_irq,
+ >affinity_mask);
+
+ hdev->affinity_notify.notify = hclge_irq_affinity_notify;
+ hdev->affinity_notify.release = hclge_irq_affinity_release;
+ irq_set_affinity_notifier(hdev->misc_vector.vector_irq,
+ >affinity_notify);
+}
+
+static void hclge_misc_affinity_teardown(struct hclge_dev *hdev)
+{
+ irq_set_affinity_notifier(hdev->misc_vector.vector_irq, NULL);
+ irq_set_affinity_hint(hdev->misc_vector.vector_irq, NULL);
+}
+
static int hclge_misc_irq_init(struct hclge_dev *hdev)
{
int ret;
@@ -8794,6 +8833,11 @@ static int hclge_init_ae_dev(struct hnae3_ae_dev *ae_dev)
INIT_WORK(>rst_service_task, hclge_reset_service_task);
INIT_WORK(>mbx_service_task, hclge_mailbox_service_task);
+ /* Setup affinity after service timer setup because add_timer_on
+* is called in affinity notify.
+*/
+ hclge_misc_affinity_setup(hdev);
+
hclge_clear_all_event_cause(hdev);
hclge_clear_resetting_state(hdev);
@@ -8955,6 +8999,7 @@ static void hclge_uninit_ae_dev(struct hnae3_ae_dev
*ae_dev)
struct hclge_dev *hdev = ae_dev->priv;
struct hclge_mac *mac = >hw.mac;
+ hclge_misc_affinity_teardown(hdev);
hclge_state_uninit(hdev);
if (mac->phydev)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
index dde8f22..688e425 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
+++
[PATCH V2 net-next 06/10] net: hns3: adds debug messages to identify eth down cause
From: Yonglong Liu
Some times just see the eth interface have been down/up via
dmesg, but can not know why the eth down. So adds some debug
messages to identify the cause for this.
Signed-off-by: Yonglong Liu
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 24
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 26 ++
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 14
3 files changed, 64 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 4d58c53..2e30cfa 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -459,6 +459,10 @@ static int hns3_nic_net_open(struct net_device *netdev)
h->ae_algo->ops->set_timer_task(priv->ae_handle, true);
hns3_config_xps(priv);
+
+ if (netif_msg_drv(h))
+ netdev_info(netdev, "net open\n");
+
return 0;
}
@@ -519,6 +523,9 @@ static int hns3_nic_net_stop(struct net_device *netdev)
if (test_and_set_bit(HNS3_NIC_STATE_DOWN, >state))
return 0;
+ if (netif_msg_drv(h))
+ netdev_info(netdev, "net stop\n");
+
if (h->ae_algo->ops->set_timer_task)
h->ae_algo->ops->set_timer_task(priv->ae_handle, false);
@@ -1550,6 +1557,9 @@ static int hns3_setup_tc(struct net_device *netdev, void
*type_data)
h = hns3_get_handle(netdev);
kinfo = >kinfo;
+ if (netif_msg_drv(h))
+ netdev_info(netdev, "setup tc: num_tc=%d\n", tc);
+
return (kinfo->dcb_ops && kinfo->dcb_ops->setup_tc) ?
kinfo->dcb_ops->setup_tc(h, tc, prio_tc) : -EOPNOTSUPP;
}
@@ -1593,6 +1603,11 @@ static int hns3_ndo_set_vf_vlan(struct net_device
*netdev, int vf, u16 vlan,
struct hnae3_handle *h = hns3_get_handle(netdev);
int ret = -EIO;
+ if (netif_msg_drv(h))
+ netdev_info(netdev,
+ "set vf vlan: vf=%d, vlan=%d, qos=%d,
vlan_proto=%d\n",
+ vf, vlan, qos, vlan_proto);
+
if (h->ae_algo->ops->set_vf_vlan_filter)
ret = h->ae_algo->ops->set_vf_vlan_filter(h, vf, vlan,
qos, vlan_proto);
@@ -1611,6 +1626,10 @@ static int hns3_nic_change_mtu(struct net_device
*netdev, int new_mtu)
if (!h->ae_algo->ops->set_mtu)
return -EOPNOTSUPP;
+ if (netif_msg_drv(h))
+ netdev_info(netdev, "change mtu from %d to %d\n",
+ netdev->mtu, new_mtu);
+
ret = h->ae_algo->ops->set_mtu(h, new_mtu);
if (ret)
netdev_err(netdev, "failed to change MTU in hardware %d\n",
@@ -4395,6 +4414,11 @@ int hns3_set_channels(struct net_device *netdev,
if (kinfo->rss_size == new_tqp_num)
return 0;
+ if (netif_msg_drv(h))
+ netdev_info(netdev,
+ "set channels: tqp_num=%d, rxfh=%d\n",
+ new_tqp_num, rxfh_configured);
+
ret = hns3_reset_notify(h, HNAE3_DOWN_CLIENT);
if (ret)
return ret;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index e71c92b..08334d7 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -311,6 +311,9 @@ static void hns3_self_test(struct net_device *ndev,
if (eth_test->flags != ETH_TEST_FL_OFFLINE)
return;
+ if (netif_msg_drv(h))
+ netdev_info(ndev, "self test start\n");
+
st_param[HNAE3_LOOP_APP][0] = HNAE3_LOOP_APP;
st_param[HNAE3_LOOP_APP][1] =
h->flags & HNAE3_SUPPORT_APP_LOOPBACK;
@@ -374,6 +377,9 @@ static void hns3_self_test(struct net_device *ndev,
if (if_running)
ndev->netdev_ops->ndo_open(ndev);
+
+ if (netif_msg_drv(h))
+ netdev_info(ndev, "self test end\n");
}
static int hns3_get_sset_count(struct net_device *netdev, int stringset)
@@ -604,6 +610,11 @@ static int hns3_set_pauseparam(struct net_device *netdev,
{
struct hnae3_handle *h = hns3_get_handle(netdev);
+ if (netif_msg_drv(h))
+ netdev_info(netdev,
+ "set pauseparam: autoneg=%d, rx:%d, tx:%d\n",
+ param->autoneg, param->rx_pause, param->tx_pause);
+
if (h->ae_algo->ops->set_pauseparam)
return h->ae_algo->ops->set_pauseparam(h, param->autoneg,
param->rx_pause,
@@ -743,6 +754,13 @@ static int hns3_set_link_ksettings(struct net_device
*netdev,
if (cmd->base.speed == SPEED_1000 && cmd->base.duplex ==
[PATCH V2 net-next 03/10] net: hns3: remove upgrade reset level when reset fail
Currently, hclge_reset_err_handle() will assert a global reset
when the failing count is smaller than MAX_RESET_FAIL_CNT, which
will affect other running functions.
So this patch removes this upgrading, and uses re-scheduling reset
task to do it.
Signed-off-by: Huazhong Tan
Reviewed-by: Yunsheng Lin
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 28 +++---
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 3fde5471..3c64d70 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3305,7 +3305,7 @@ static int hclge_reset_prepare_wait(struct hclge_dev
*hdev)
return ret;
}
-static bool hclge_reset_err_handle(struct hclge_dev *hdev, bool is_timeout)
+static bool hclge_reset_err_handle(struct hclge_dev *hdev)
{
#define MAX_RESET_FAIL_CNT 5
@@ -3322,20 +3322,11 @@ static bool hclge_reset_err_handle(struct hclge_dev
*hdev, bool is_timeout)
return false;
} else if (hdev->reset_fail_cnt < MAX_RESET_FAIL_CNT) {
hdev->reset_fail_cnt++;
- if (is_timeout) {
- set_bit(hdev->reset_type, >reset_pending);
- dev_info(>pdev->dev,
-"re-schedule to wait for hw reset done\n");
- return true;
- }
-
- dev_info(>pdev->dev, "Upgrade reset level\n");
- hclge_clear_reset_cause(hdev);
- set_bit(HNAE3_GLOBAL_RESET, >default_reset_request);
- mod_timer(>reset_timer,
- jiffies + HCLGE_RESET_INTERVAL);
-
- return false;
+ set_bit(hdev->reset_type, >reset_pending);
+ dev_info(>pdev->dev,
+"re-schedule reset task(%d)\n",
+hdev->reset_fail_cnt);
+ return true;
}
hclge_clear_reset_cause(hdev);
@@ -3382,7 +3373,6 @@ static int hclge_reset_stack(struct hclge_dev *hdev)
static void hclge_reset(struct hclge_dev *hdev)
{
struct hnae3_ae_dev *ae_dev = pci_get_drvdata(hdev->pdev);
- bool is_timeout = false;
int ret;
/* Initialize ae_dev reset status as well, in case enet layer wants to
@@ -3410,10 +3400,8 @@ static void hclge_reset(struct hclge_dev *hdev)
if (ret)
goto err_reset;
- if (hclge_reset_wait(hdev)) {
- is_timeout = true;
+ if (hclge_reset_wait(hdev))
goto err_reset;
- }
hdev->rst_stats.hw_reset_done_cnt++;
@@ -3465,7 +3453,7 @@ static void hclge_reset(struct hclge_dev *hdev)
err_reset_lock:
rtnl_unlock();
err_reset:
- if (hclge_reset_err_handle(hdev, is_timeout))
+ if (hclge_reset_err_handle(hdev))
hclge_reset_task_schedule(hdev);
}
--
2.7.4
[PATCH V2 net-next 09/10] net: hns3: Add support for using order 1 pages with a 4K buffer
From: Yunsheng Lin
Hardware supports 0.5K, 1K, 2K, 4K RX buffer size, the
RX buffer can not be reused because the hns3_page_order
return 0 when page size and RX buffer size are both 4096.
So this patch changes the hns3_page_order to return 1 when
RX buffer is greater than half of the page size and page size
is less the 8192, and dev_alloc_pages has already been used
to allocate the compound page for RX buffer.
This patch also changes hnae3_* to hns3_* for page order
and RX buffer size calculation because they are used in
hns3 module.
Signed-off-by: Yunsheng Lin
Reviewed-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 10 +-
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 15 ---
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 2e30cfa..3a93bef 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2086,7 +2086,7 @@ static void hns3_set_default_feature(struct net_device
*netdev)
static int hns3_alloc_buffer(struct hns3_enet_ring *ring,
struct hns3_desc_cb *cb)
{
- unsigned int order = hnae3_page_order(ring);
+ unsigned int order = hns3_page_order(ring);
struct page *p;
p = dev_alloc_pages(order);
@@ -2097,7 +2097,7 @@ static int hns3_alloc_buffer(struct hns3_enet_ring *ring,
cb->page_offset = 0;
cb->reuse_flag = 0;
cb->buf = page_address(p);
- cb->length = hnae3_page_size(ring);
+ cb->length = hns3_page_size(ring);
cb->type = DESC_TYPE_PAGE;
return 0;
@@ -2400,7 +2400,7 @@ static void hns3_nic_reuse_page(struct sk_buff *skb, int
i,
{
struct hns3_desc *desc = >desc[ring->next_to_clean];
int size = le16_to_cpu(desc->rx.size);
- u32 truesize = hnae3_buf_size(ring);
+ u32 truesize = hns3_buf_size(ring);
skb_add_rx_frag(skb, i, desc_cb->priv, desc_cb->page_offset + pull_len,
size - pull_len, truesize);
@@ -2415,7 +2415,7 @@ static void hns3_nic_reuse_page(struct sk_buff *skb, int
i,
/* Move offset up to the next cache line */
desc_cb->page_offset += truesize;
- if (desc_cb->page_offset + truesize <= hnae3_page_size(ring)) {
+ if (desc_cb->page_offset + truesize <= hns3_page_size(ring)) {
desc_cb->reuse_flag = 1;
/* Bump ref count on page before it is given */
get_page(desc_cb->priv);
@@ -2697,7 +2697,7 @@ static int hns3_add_frag(struct hns3_enet_ring *ring,
struct hns3_desc *desc,
}
if (ring->tail_skb) {
- head_skb->truesize += hnae3_buf_size(ring);
+ head_skb->truesize += hns3_buf_size(ring);
head_skb->data_len += le16_to_cpu(desc->rx.size);
head_skb->len += le16_to_cpu(desc->rx.size);
skb = ring->tail_skb;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
index 848b866..1a17856 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
@@ -608,9 +608,18 @@ static inline bool hns3_nic_resetting(struct net_device
*netdev)
#define tx_ring_data(priv, idx) ((priv)->ring_data[idx])
-#define hnae3_buf_size(_ring) ((_ring)->buf_size)
-#define hnae3_page_order(_ring) (get_order(hnae3_buf_size(_ring)))
-#define hnae3_page_size(_ring) (PAGE_SIZE << (u32)hnae3_page_order(_ring))
+#define hns3_buf_size(_ring) ((_ring)->buf_size)
+
+static inline unsigned int hns3_page_order(struct hns3_enet_ring *ring)
+{
+#if (PAGE_SIZE < 8192)
+ if (ring->buf_size > (PAGE_SIZE / 2))
+ return 1;
+#endif
+ return 0;
+}
+
+#define hns3_page_size(_ring) (PAGE_SIZE << hns3_page_order(_ring))
/* iterator for handling rings in ring group */
#define hns3_for_each_ring(pos, head) \
--
2.7.4
[PATCH V2 net-next 04/10] net: hns3: change GFP flag during lock period
From: Yufeng Mo
When allocating memory, the GFP_KERNEL cannot be used during the
spin_lock period. This is because it may cause scheduling when holding
spin_lock. This patch changes GFP flag to GFP_ATOMIC in this case.
Fixes: dd74f815dd41 ("net: hns3: Add support for rule add/delete for flow
director")
Signed-off-by: Yufeng Mo
Signed-off-by: lipeng 00277521
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 3c64d70..14199c4 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -5796,7 +5796,7 @@ static int hclge_add_fd_entry_by_arfs(struct hnae3_handle
*handle, u16 queue_id,
return -ENOSPC;
}
- rule = kzalloc(sizeof(*rule), GFP_KERNEL);
+ rule = kzalloc(sizeof(*rule), GFP_ATOMIC);
if (!rule) {
spin_unlock_bh(>fd_rule_lock);
--
2.7.4
Re: [PATCH v1] ACPI / scan: Acquire device_hotplug_lock in acpi_scan_init()
On Thu 25-07-19 22:49:36, David Hildenbrand wrote: > On 25.07.19 21:19, Michal Hocko wrote: [...] > > We need to rationalize the locking here, not to add more hacks. > > No, sorry. The real hack is calling a function that is *documented* to > be called under lock without it. That is an optimization for a special > case. That is the black magic in the code. OK, let me ask differently. What does the device_hotplug_lock actually protects from in the add_memory path? (Which data structures) This function is meant to be used when struct pages and node/zone data structures should be updated. Why should we even care about some device concept here? This should all be handled a layer up. Not all memory will have user space API to control online/offline state. -- Michal Hocko SUSE Labs
Re: [RFC][PATCH 1/5] exit: kill struct waitid_info
On Thu, Jul 25, 2019 at 07:46:50AM -0500, Eric W. Biederman wrote:
> Linus Torvalds writes:
>
> > On Wed, Jul 24, 2019 at 7:47 AM Christian Brauner
> > wrote:
> >>
> >> The code here uses a struct waitid_info to catch basic information about
> >> process exit including the pid, uid, status, and signal that caused the
> >> process to exit. This information is then stuffed into a struct siginfo
> >> for the waitid() syscall. That seems like an odd thing to do. We can
> >> just pass down a siginfo_t struct directly which let's us cleanup and
> >> simplify the whole code quite a bit.
> >
> > Ack. Except I'd like the commit message to explain where this comes
> > from instead of that "That seems like an odd thing to do".
> >
> > The _original_ reason for "struct waitid_info" was that "siginfo_t" is
> > huge because of all the insane padding that various architectures do.
> >
> > So it was introduced by commit 67d7ddded322 ("waitid(2): leave copyout
> > of siginfo to syscall itself") very much to avoid stack usage issues.
> > And I quote:
> >
> > collect the information needed for siginfo into
> > a small structure (waitid_info)
> >
> > simply because "sigset_t" was big.
> >
> > But that size came from the explicit "pad it out to 128 bytes for
> > future expansion that will never happen", and the kernel using the
> > same exact sigset_t that was exposed to user space.
> >
> > Then in commit 4ce5f9c9e754 ("signal: Use a smaller struct siginfo in
> > the kernel") we got rid of the insane padding for in-kernel use,
> > exactly because it causes issues like this.
> >
> > End result: that "struct waitid_info" no longer makes sense. It's not
> > appreciably smaller than kernel_siginfo_t is today, but it made sense
> > at the time.
>
> Apologies. I meant to reply yesterday but I was preempted by baby
> issues.
>
> I strongly disagree that this direction makes sense. The largest
> value that I see from struct waitid_info is that it makes it possible to
> reason about which values are returned where struct kernel_siginfo does
> not.
>
> One of the details the existence of struct waitid_info makes clear is
> that unlike the related child death path the wait code does not
> fillin si_utime and si_stime. Which is very important to know when you
> are dealing with y2038 issues and Arnd Bergmann is.
>
> The most egregious example I know of using siginfo wrong is:
> 70f1b0d34bdf ("signal/usb: Replace kill_pid_info_as_cred with
> kill_pid_usb_asyncio"). But just by moving struct siginfo out of the
> program logic and into dedicated little functions that just deal with
> the craziness of struct siginfo I have found lots of little bugs.
>
> We don't need that kind of invitation to bugs in the wait logic.
I don't think it's a strong enough argument for rejecting this change.
Suspecting that something might go wrong if we simplify something is a
valid call to proceed with caution and be on the lookout for potential
regressions so we can react fast. I respect that. But it's not
necessarily a good argument to reject a change.
I'm happy to switch from an initializer (which is not even clear is a
bug) to using clear_siginfo().
And I'm also going to split this patch out of the P_PIDFD patch but I'm
going to send this out again. I haven't heard a sound argument why this
patch is worse than what we have right now in there.
Christian
[PATCH] iio: humidity: Use device-managed APIs
Use device-managed APIs to simplify the code.
The remove functions are redundant now and can
be deleted.
Signed-off-by: Chuhong Yuan
---
drivers/iio/humidity/am2315.c | 21 -
drivers/iio/humidity/hdc100x.c | 18 --
2 files changed, 8 insertions(+), 31 deletions(-)
diff --git a/drivers/iio/humidity/am2315.c b/drivers/iio/humidity/am2315.c
index f18da7859229..038638e92f4a 100644
--- a/drivers/iio/humidity/am2315.c
+++ b/drivers/iio/humidity/am2315.c
@@ -240,32 +240,20 @@ static int am2315_probe(struct i2c_client *client,
indio_dev->channels = am2315_channels;
indio_dev->num_channels = ARRAY_SIZE(am2315_channels);
- ret = iio_triggered_buffer_setup(indio_dev, iio_pollfunc_store_time,
+ ret = devm_iio_triggered_buffer_setup(>dev,
+ indio_dev, iio_pollfunc_store_time,
am2315_trigger_handler, NULL);
if (ret < 0) {
dev_err(>dev, "iio triggered buffer setup failed\n");
return ret;
}
- ret = iio_device_register(indio_dev);
+ ret = devm_iio_device_register(>dev, indio_dev);
if (ret < 0)
- goto err_buffer_cleanup;
+ return ret;
return 0;
-err_buffer_cleanup:
- iio_triggered_buffer_cleanup(indio_dev);
- return ret;
-}
-
-static int am2315_remove(struct i2c_client *client)
-{
- struct iio_dev *indio_dev = i2c_get_clientdata(client);
-
- iio_device_unregister(indio_dev);
- iio_triggered_buffer_cleanup(indio_dev);
-
- return 0;
}
static const struct i2c_device_id am2315_i2c_id[] = {
@@ -287,7 +275,6 @@ static struct i2c_driver am2315_driver = {
.acpi_match_table = ACPI_PTR(am2315_acpi_id),
},
.probe =am2315_probe,
- .remove = am2315_remove,
.id_table = am2315_i2c_id,
};
diff --git a/drivers/iio/humidity/hdc100x.c b/drivers/iio/humidity/hdc100x.c
index 066e05f92081..5186fd9bfdc5 100644
--- a/drivers/iio/humidity/hdc100x.c
+++ b/drivers/iio/humidity/hdc100x.c
@@ -385,26 +385,17 @@ static int hdc100x_probe(struct i2c_client *client,
hdc100x_set_it_time(data, 1, hdc100x_int_time[1][0]);
hdc100x_update_config(data, HDC100X_REG_CONFIG_ACQ_MODE, 0);
- ret = iio_triggered_buffer_setup(indio_dev, NULL,
+ ret = devm_iio_triggered_buffer_setup(>dev,
+indio_dev, NULL,
hdc100x_trigger_handler,
_buffer_setup_ops);
if (ret < 0) {
dev_err(>dev, "iio triggered buffer setup failed\n");
return ret;
}
- ret = iio_device_register(indio_dev);
+ ret = devm_iio_device_register(>dev, indio_dev);
if (ret < 0)
- iio_triggered_buffer_cleanup(indio_dev);
-
- return ret;
-}
-
-static int hdc100x_remove(struct i2c_client *client)
-{
- struct iio_dev *indio_dev = i2c_get_clientdata(client);
-
- iio_device_unregister(indio_dev);
- iio_triggered_buffer_cleanup(indio_dev);
+ return ret;
return 0;
}
@@ -436,7 +427,6 @@ static struct i2c_driver hdc100x_driver = {
.of_match_table = of_match_ptr(hdc100x_dt_ids),
},
.probe = hdc100x_probe,
- .remove = hdc100x_remove,
.id_table = hdc100x_id,
};
module_i2c_driver(hdc100x_driver);
--
2.20.1
[PATCH 2/2] net: ipv6: Fix a possible null-pointer dereference in vti6_link_config()
In vti6_link_config(), there is an if statement on line 649 to check
whether rt is NULL:
if (rt)
When rt is NULL, it is used on line 651:
ip6_rt_put(rt);
dst_release(>dst);
Thus, a possible null-pointer dereference may occur.
To fix this bug, ip6_rt_put() is called when rt is not NULL.
This bug is found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai
---
net/ipv6/ip6_vti.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
index 024db17386d2..572647205c52 100644
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -646,9 +646,10 @@ static void vti6_link_config(struct ip6_tnl *t, bool
keep_mtu)
>raddr, >laddr,
p->link, NULL, strict);
- if (rt)
+ if (rt) {
tdev = rt->dst.dev;
- ip6_rt_put(rt);
+ ip6_rt_put(rt);
+ }
}
if (!tdev && p->link)
--
2.17.0
[PATCH 1/2] net: ipv6: Fix a possible null-pointer dereference in ip6_xmit()
In ip6_xmit(), there is an if statement on line 245 to check whether
np is NULL:
if (np)
When np is NULL, it is used on line 251:
ip6_autoflowlabel(net, np)
if (!np->autoflowlabel_set)
Thus, a possible null-pointer dereference may occur.
To fix this bug, np is checked before calling
ip6_autoflowlabel(net,np).
This bug is found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai
---
net/ipv6/ip6_output.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 8e49fd62eea9..07db5ab6e970 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -247,8 +247,10 @@ int ip6_xmit(const struct sock *sk, struct sk_buff *skb,
struct flowi6 *fl6,
if (hlimit < 0)
hlimit = ip6_dst_hoplimit(dst);
- ip6_flow_hdr(hdr, tclass, ip6_make_flowlabel(net, skb, fl6->flowlabel,
- ip6_autoflowlabel(net, np), fl6));
+ if (np) {
+ ip6_flow_hdr(hdr, tclass, ip6_make_flowlabel(net, skb,
fl6->flowlabel,
+ ip6_autoflowlabel(net, np), fl6));
+ }
hdr->payload_len = htons(seg_len);
hdr->nexthdr = proto;
--
2.17.0
Re: [PATCH v2 01/14] opp: Add dev_pm_opp_find_level_exact()
On 25-07-19, 12:41, Niklas Cassel wrote: > When using performance states, there is usually not any opp-hz property > specified, so the dev_pm_opp_find_freq_exact() function cannot be used. Removed above two lines while applying. > Since the performance states in the OPP table are unique, implement a > dev_pm_opp_find_level_exact() in order to be able to fetch a specific OPP. > > Signed-off-by: Niklas Cassel > --- > drivers/opp/core.c | 48 ++ > include/linux/pm_opp.h | 8 +++ > 2 files changed, 56 insertions(+) -- viresh
Re: [PATCH v2 02/14] dt-bindings: cpufreq: Re-organise kryo cpufreq to use it for other nvmem based qcom socs
$subject of this and few more binding patches updated to: "dt-bindings: opp: XXX" On 25-07-19, 12:41, Niklas Cassel wrote: > From: Sricharan R > > The kryo cpufreq driver reads the nvmem cell and uses that data to > populate the opps. There are other qcom cpufreq socs like krait which > does similar thing. Except for the interpretation of the read data, > rest of the driver is same for both the cases. So pull the common things > out for reuse. > > Signed-off-by: Sricharan R > [niklas.cas...@linaro.org: split dt-binding into a separate patch and > do not rename the compatible string.] > Signed-off-by: Niklas Cassel > Reviewed-by: Ilia Lin > Reviewed-by: Rob Herring > --- > Changes since V1: > -Picked up tags. -- viresh
Re: [PATCH v1] ACPI / scan: Acquire device_hotplug_lock in acpi_scan_init()
On 26.07.19 09:57, Michal Hocko wrote: > On Thu 25-07-19 22:49:36, David Hildenbrand wrote: >> On 25.07.19 21:19, Michal Hocko wrote: > [...] >>> We need to rationalize the locking here, not to add more hacks. >> >> No, sorry. The real hack is calling a function that is *documented* to >> be called under lock without it. That is an optimization for a special >> case. That is the black magic in the code. > > OK, let me ask differently. What does the device_hotplug_lock actually > protects from in the add_memory path? (Which data structures) > > This function is meant to be used when struct pages and node/zone data > structures should be updated. Why should we even care about some device > concept here? This should all be handled a layer up. Not all memory will > have user space API to control online/offline state. Via add_memory()/__add_memory() we create memory block devices for all memory. So all memory we create via this function (IOW, hotplug) will have user space APIs. Sorry, I can't follow what you are saying here - are you confusing the function we are talking about with arch_add_memory() ? (where I pulled out the creation of memory block devices) -- Thanks, David / dhildenb
Re: [PATCH 04/17] ARM: dts: vesnin: Add unit address for memory node
On Fri, Jul 26, 2019 at 03:09:46PM +0930, Andrew Jeffery wrote:
> Fixes the following warnings:
>
> arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dt.yaml: /: memory: False schema
> does not allow {'reg': [[1073741824, 536870912]]}
> arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dt.yaml: memory: 'device_type' is
> a required property
>
> Cc: Alexander Filippov
> Signed-off-by: Andrew Jeffery
> ---
> arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
> b/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
> index 0b9e29c3212e..81d9dcb752a0 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
> @@ -14,7 +14,7 @@
> bootargs = "console=ttyS4,115200 earlyprintk";
> };
>
> - memory {
> + memory@4000 {
> reg = <0x4000 0x2000>;
> };
>
> --
> 2.20.1
>
Tested-by: Alexander Filippov
Re: [PATCH v2 00/14] Add support for QCOM Core Power Reduction
On 25-07-19, 12:41, Niklas Cassel wrote: > This series adds support for Core Power Reduction (CPR), a form of > Adaptive Voltage Scaling (AVS), found on certain Qualcomm SoCs. > > This series is based on top of the qcs404 cpufreq patch series that > hasn't landed yet: > https://patchwork.kernel.org/project/linux-arm-msm/list/?series=137809 > > CPR is a technology that reduces core power on a CPU or on other device. > It reads voltage settings from efuses (that have been written in > production), it uses these voltage settings as initial values, for each > OPP. > > After moving to a certain OPP, CPR monitors dynamic factors such as > temperature, etc. and adjusts the voltage for that frequency accordingly > to save power and meet silicon characteristic requirements. > > This driver has been developed together with Jorge Ramirez-Ortiz, and > is based on an RFC by Stephen Boyd[1], which in turn is based on work > by others on codeaurora.org[2]. > > [1] https://lkml.org/lkml/2015/9/18/833 > [2] > https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/drivers/regulator/cpr-regulator.c?h=msm-3.10 > > Changes since V1: > Added a new patch implementing dev_pm_opp_find_level_exact() in order to > make the CPR OPP table in device tree cleaner. > For more detailed changes, check the "Changes since V1" as comments in > the individual patches, where applicable. Applied patches [1-9/14] to cpufreq and OPP trees and done some reordering as well to keep all binding patches together. Rob's Ack is missing on two of the binding patches and I will add them later once he provides it. Everything should be available here for you to base rest of the stuff. git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git cpufreq/arm/linux-next -- viresh
Re: Re: [PATCH v6] serial/8250: Add support for NI-Serial PXI/PXIe+485 devices
On Fri, Jul 26, 2019 at 07:33:28AM +, Je Yen Tam wrote: > > Subject: [EXTERNAL] Re: [PATCH v6] serial/8250: Add support for NI-Serial > > PXI/PXIe+485 devices > > > > On Fri, Jul 26, 2019 at 03:22:26PM +0800, jeyentam wrote: > > > Add support for NI-Serial PXIe-RS232, PXI-RS485 and PXIe-RS485 devices. > > > > > > Signed-off-by: Je Yen Tam > > > > "From:" name does not match the Signed-off-by: name :( > > Change it in v7? > Please do.
Re: WARNING in ovl_real_fdget_meta
On Thu, Jul 25, 2019 at 7:24 AM syzbot
wrote:
>
> syzbot has bisected this bug to:
>
> commit 387e3746d01c34457d6a73688acd90428725070b
> Author: Amir Goldstein
> Date: Fri Jun 7 14:24:38 2019 +
>
> locks: eliminate false positive conflicts for write lease
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15a7959460
> start commit: c6dd78fc Merge branch 'x86-urgent-for-linus' of git://git...
> git tree: upstream
> final crash:https://syzkaller.appspot.com/x/report.txt?x=17a7959460
> console output: https://syzkaller.appspot.com/x/log.txt?x=13a7959460
> kernel config: https://syzkaller.appspot.com/x/.config?x=3c8985c08e1f9727
> dashboard link: https://syzkaller.appspot.com/bug?extid=032bc63605089a199d30
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1585533460
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17fcc4c860
>
> Reported-by: syzbot+032bc63605089a199...@syzkaller.appspotmail.com
> Fixes: 387e3746d01c ("locks: eliminate false positive conflicts for write
> lease")
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
The repro:
#{"repeat":true,"procs":1,"sandbox":"none","fault_call":-1,"cgroups":true,"close_fds":true,"tmpdir":true}
mkdir(&(0x7f000100)='./file0\x00', 0x0)
mkdirat$cgroup_root(0xff9c,
&(0x7f00)='./cgroup.net/syz1\x00', 0x1ff)
mount$fuse(0x2000, &(0x7f000140)='./file0\x00', 0x0, 0x1004, 0x0)
mount$overlay(0x40, &(0x7f000100)='./file0\x00',
&(0x7f0001c0)='overlay\x00', 0x0,
&(0x7f40)=ANY=[@ANYBLOB=',lowerdir=.:file0'])
r0 = open(&(0x7f000500)='./file0\x00', 0x0, 0x0)
r1 = openat$cgroup_procs(r0, &(0x7f0004c0)='cgroup.procs\x00', 0x48, 0x0)
dup3(r1, r0, 0x0)
fcntl$setlease(r0, 0x400, 0x1)
lseek(r0, 0x4, 0x0)
I though we would stop these family of overlapping layers fuzzers with:
146d62e5a586 ("ovl: detect overlapping layers")
But syzbot got the upper hand, because we do not check for overlapping layers
that cross fs boundary. Not sure if we should (?).
./ is a tmpfs dir and ./file0/ is some kind of fuse mount (?)
then after one cycle, ./file0/ itself is an overlapping overlay mount
(lowerdir=./:./file0/)
and after another cycle, ./file0/ is a nested overlapping overlayfs mount.
Fine. Whatever.
What I don't understand is if dup3 succeeds r0 should not be an overlayfs fd
and even if dup3 fails r0 should be an overlayfs directory fd (./file0/), so how
the hell did we get to ovl_llseek => ... ovl_change_flags() with this repro??
There is not a single regular file in this test.
Thanks,
Amir.
Re: [RFC PATCH 1/3] mm, reclaim: make should_continue_reclaim perform dryrun detection
> From: Hillf Danton > Subject: [RFC PATCH 1/3] mm, reclaim: make should_continue_reclaim perform > dryrun detection > > Address the issue of should_continue_reclaim continuing true too often > for __GFP_RETRY_MAYFAIL attempts when !nr_reclaimed and nr_scanned. > This could happen during hugetlb page allocation causing stalls for > minutes or hours. > > We can stop reclaiming pages if compaction reports it can make a progress. > A code reshuffle is needed to do that. And it has side-effects, however, > with allocation latencies in other cases but that would come at the cost > of potential premature reclaim which has consequences of itself. > > We can also bail out of reclaiming pages if we know that there are not > enough inactive lru pages left to satisfy the costly allocation. > > We can give up reclaiming pages too if we see dryrun occur, with the > certainty of plenty of inactive pages. IOW with dryrun detected, we are > sure we have reclaimed as many pages as we could. > > Cc: Mike Kravetz > Cc: Mel Gorman > Cc: Michal Hocko > Cc: Vlastimil Babka > Cc: Johannes Weiner > Signed-off-by: Hillf Danton Acked-by: Mel Gorman Thanks Hillf -- Mel Gorman SUSE Labs
Re: [PATCH] mfd: max77620: Add of_node_put() before return
On 25/07/19 5:45 PM, Lee Jones wrote:
On Tue, 09 Jul 2019, Nishka Dasgupta wrote:
Each iteration of for_each_child_of_node puts the previous node, but in
the case of a return from the middle of the loop, there is no put, thus
causing a memory leak. Hence add an of_node_put before the return.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/mfd/max77620.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Ah, I've just seen that you didn't send this to the list.
When submitting patches upstream, you must CC at least one list.
Usually people CC LKML as a matter of course.
My mistake, sorry. I'll CC the list from next time.
Thanking you,
Nishka
I've CC'ed LMKL here and applied the patch.
diff --git a/drivers/mfd/max77620.c b/drivers/mfd/max77620.c
index 0c28965fcc6a..a851ff473a44 100644
--- a/drivers/mfd/max77620.c
+++ b/drivers/mfd/max77620.c
@@ -416,8 +416,10 @@ static int max77620_initialise_fps(struct max77620_chip
*chip)
for_each_child_of_node(fps_np, fps_child) {
ret = max77620_config_fps(chip, fps_child);
- if (ret < 0)
+ if (ret < 0) {
+ of_node_put(fps_child);
return ret;
+ }
}
config = chip->enable_global_lpm ? MAX77620_ONOFFCNFG2_SLP_LPM_MSK : 0;
Re: [PATCH v7] serial/8250: Add support for NI-Serial PXI/PXIe+485 devices
On Fri, Jul 26, 2019 at 03:40:12PM +0800, Je Yen Tam wrote: > Add support for NI-Serial PXIe-RS232, PXI-RS485 and PXIe-RS485 devices. > > Signed-off-by: Je Yen Tam Looks good, now queued up, thanks for all of the revisions. greg k-h
Re: [PATCH RFC] mm/memory_hotplug: Don't take the cpu_hotplug_lock
On Thu 25-07-19 11:22:06, David Hildenbrand wrote:
> Commit 9852a7212324 ("mm: drop hotplug lock from lru_add_drain_all()")
> states that lru_add_drain_all() "Doesn't need any cpu hotplug locking
> because we do rely on per-cpu kworkers being shut down before our
> page_alloc_cpu_dead callback is executed on the offlined cpu."
>
> And also "Calling this function with cpu hotplug locks held can actually
> lead to obscure indirect dependencies via WQ context.".
>
> Since commit 3f906ba23689 ("mm/memory-hotplug: switch locking to a percpu
> rwsem") we do a cpus_read_lock() in mem_hotplug_begin().
>
> I don't see how that lock is still helpful, we already hold the
> device_hotplug_lock to protect try_offline_node(), which is AFAIK one
> problematic part that can race with CPU hotplug. If it is still
> necessary, we should document why.
I have forgot all the juicy details. Maybe Thomas remembers. The
previous recursive home grown locking was just terrible. I do not see
stop_machine being used in the memory hotplug anymore.
I do support this kind of removal because binding CPU and MEM hotplug
locks is fragile and wrong. But this patch really needs more explanation
on why this is safe. In other words what does cpu_read_lock protects
from in mem hotplug paths.
> Cc: Andrew Morton
> Cc: Oscar Salvador
> Cc: Michal Hocko
> Cc: Pavel Tatashin
> Cc: Dan Williams
> Cc: Thomas Gleixner
> Signed-off-by: David Hildenbrand
> ---
> mm/memory_hotplug.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index e7c3b219a305..43b8cd4b96f5 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -86,14 +86,12 @@ __setup("memhp_default_state=",
> setup_memhp_default_state);
>
> void mem_hotplug_begin(void)
> {
> - cpus_read_lock();
> percpu_down_write(_hotplug_lock);
> }
>
> void mem_hotplug_done(void)
> {
> percpu_up_write(_hotplug_lock);
> - cpus_read_unlock();
> }
>
> u64 max_mem_size = U64_MAX;
> --
> 2.21.0
--
Michal Hocko
SUSE Labs
Re: [PATCH 2/5] pidfd: add pidfd_wait()
On Wed, Jul 24, 2019 at 4:47 PM Christian Brauner wrote:
> +
> +static int copy_rusage_to_user_any(struct rusage *kru, struct rusage __user
> *ru)
> +{
> +#ifdef CONFIG_COMPAT
> + if (in_compat_syscall())
> + return put_compat_rusage(kru, (struct compat_rusage __user
> *)ru);
> +#endif
> + return copy_to_user(ru, kru, sizeof(*kru));
> +}
I think this code needs a check for COMPAT_USE_64BIT_TIME in order
to handle x32 correctly.
It would be nice to introduce it in a separate patch, and then use it
to kill off
compat_sys_getrusage() and compat_sys_wait4(), and possibly even
compat_sys_waitid() in combination with your copy_siginfo_to_user_any().
That could be done as a cleanup patch afterwards, or as part of your series.
Arnd
Re: [Regression] Missing device nodes for ETR, ETF and STM after CONFIG_UEVENT_HELPER=n
On 7/26/2019 12:34 PM, Greg Kroah-Hartman wrote:
On Fri, Jul 26, 2019 at 11:49:19AM +0530, Sai Prakash Ranjan wrote:
Hi,
When trying to test my coresight patches, I found that etr,etf and stm
device nodes are missing from /dev.
I have no idea what those device nodes are.
Bisection gives this as the bad commit.
1be01d4a57142ded23bdb9e0c8d9369e693b26cc is the first bad commit
commit 1be01d4a57142ded23bdb9e0c8d9369e693b26cc
Author: Geert Uytterhoeven
Date: Thu Mar 14 12:13:50 2019 +0100
driver: base: Disable CONFIG_UEVENT_HELPER by default
Since commit 7934779a69f1184f ("Driver-Core: disable /sbin/hotplug by
default"), the help text for the /sbin/hotplug fork-bomb says
"This should not be used today [...] creates a high system load, or
[...] out-of-memory situations during bootup". The rationale for this
was that no recent mainstream system used this anymore (in 2010!).
A few years later, the complete uevent helper support was made optional
in commit 86d56134f1b67d0c ("kobject: Make support for uevent_helper
optional."). However, if was still left enabled by default, to support
ancient userland.
Time passed by, and nothing should use this anymore, so it can be
disabled by default.
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Greg Kroah-Hartman
drivers/base/Kconfig | 1 -
1 file changed, 1 deletion(-)
Any idea on this?
That means that who ever created those device nodes is relying on udev
to do this, and is not doing the correct thing within the kernel and
using devtmpfs.
Any pointers to where in the kernel those devices are trying to be
created?
Somewhere in drivers/hwtracing/coresight/* probably. I am not sure,
Mathieu/Suzuki would be able to point you to the exact code.
Also just to add on some more details, I am using *initramfs*
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH RFC] mm/memory_hotplug: Don't take the cpu_hotplug_lock
On 26.07.19 10:19, Michal Hocko wrote:
> On Thu 25-07-19 11:22:06, David Hildenbrand wrote:
>> Commit 9852a7212324 ("mm: drop hotplug lock from lru_add_drain_all()")
>> states that lru_add_drain_all() "Doesn't need any cpu hotplug locking
>> because we do rely on per-cpu kworkers being shut down before our
>> page_alloc_cpu_dead callback is executed on the offlined cpu."
>>
>> And also "Calling this function with cpu hotplug locks held can actually
>> lead to obscure indirect dependencies via WQ context.".
>>
>> Since commit 3f906ba23689 ("mm/memory-hotplug: switch locking to a percpu
>> rwsem") we do a cpus_read_lock() in mem_hotplug_begin().
>>
>> I don't see how that lock is still helpful, we already hold the
>> device_hotplug_lock to protect try_offline_node(), which is AFAIK one
>> problematic part that can race with CPU hotplug. If it is still
>> necessary, we should document why.
>
> I have forgot all the juicy details. Maybe Thomas remembers. The
> previous recursive home grown locking was just terrible. I do not see
> stop_machine being used in the memory hotplug anymore.
>
> I do support this kind of removal because binding CPU and MEM hotplug
> locks is fragile and wrong. But this patch really needs more explanation
> on why this is safe. In other words what does cpu_read_lock protects
> from in mem hotplug paths.
And that is the purpose of marking this RFC, because I am not aware of
any :) Hopefully Thomas can clarify if we are missing something
important (undocumented) here - if so I'll document it.
--
Thanks,
David / dhildenb
Re: [alsa-devel] [RFC PATCH 17/40] soundwire: bus: use runtime_pm_get_sync/pm when enabled
Hi Jan,
On Fri, Jul 26, 2019 at 07:47:04AM +, Jan Kotas wrote:
> Hello,
>
> I while back I proposed a patch for this, but it went nowhere.
>
> https://patchwork.kernel.org/patch/10887405/
> Maybe something similar can be implemented?
Yes, I was thinking about checkint -EACCESS too, but then I noticed this code
in rpm_resume():
else if (dev->power.disable_depth == 1 && dev->power.is_suspended
&& dev->power.runtime_status == RPM_ACTIVE)
retval = 1;
i.e. if RT-PM is disabled on the device (but only exactly once?..) and it's
active and the device is suspended for a system suspend, the function will
return 1. I don't understand the logic of this code, but it seems to me it
could break the -EACCESS check?
Thanks
Guennadi
> Jan
>
> > On 26 Jul 2019, at 09:39, Guennadi Liakhovetski
> > wrote:
> >
> > EXTERNAL MAIL
> >
> >
> > Hi Pierre,
> >
> > I might be wrong but this doesn't seem right to me. (Supposedly) all RT-PM
> > functions check for "enabled" internally. The only thing that can happen is
> > that if RT-PM isn't enabled some of those functions will return an error.
> > So, in those cases where the return value of RT-PM functions isn't checked,
> > I don't think you need to do anything. Where it is checked maybe do
> >
> > + if (ret < 0 && pm_runtime_enabled(slave->bus->dev))
> >
> > Thanks
> > Guennadi
> >
> > On Thu, Jul 25, 2019 at 06:40:09PM -0500, Pierre-Louis Bossart wrote:
> >> Not all platforms support runtime_pm for now, let's use runtime_pm
> >> only when enabled.
> >>
> >> Suggested-by: Srinivas Kandagatla
> >> Signed-off-by: Pierre-Louis Bossart
> >> ---
> >> drivers/soundwire/bus.c | 25 -
> >> 1 file changed, 16 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
> >> index 5ad4109dc72f..0a45dc5713df 100644
> >> --- a/drivers/soundwire/bus.c
> >> +++ b/drivers/soundwire/bus.c
> >> @@ -332,12 +332,16 @@ int sdw_nread(struct sdw_slave *slave, u32 addr,
> >> size_t count, u8 *val)
> >>if (ret < 0)
> >>return ret;
> >>
> >> - ret = pm_runtime_get_sync(slave->bus->dev);
> >> - if (ret < 0)
> >> - return ret;
> >> + if (pm_runtime_enabled(slave->bus->dev)) {
> >> + ret = pm_runtime_get_sync(slave->bus->dev);
> >> + if (ret < 0)
> >> + return ret;
> >> + }
> >>
> >>ret = sdw_transfer(slave->bus, );
> >> - pm_runtime_put(slave->bus->dev);
> >> +
> >> + if (pm_runtime_enabled(slave->bus->dev))
> >> + pm_runtime_put(slave->bus->dev);
> >>
> >>return ret;
> >> }
> >> @@ -359,13 +363,16 @@ int sdw_nwrite(struct sdw_slave *slave, u32 addr,
> >> size_t count, u8 *val)
> >> slave->dev_num, SDW_MSG_FLAG_WRITE, val);
> >>if (ret < 0)
> >>return ret;
> >> -
> >> - ret = pm_runtime_get_sync(slave->bus->dev);
> >> - if (ret < 0)
> >> - return ret;
> >> + if (pm_runtime_enabled(slave->bus->dev)) {
> >> + ret = pm_runtime_get_sync(slave->bus->dev);
> >> + if (ret < 0)
> >> + return ret;
> >> + }
> >>
> >>ret = sdw_transfer(slave->bus, );
> >> - pm_runtime_put(slave->bus->dev);
> >> +
> >> + if (pm_runtime_enabled(slave->bus->dev))
> >> + pm_runtime_put(slave->bus->dev);
> >>
> >>return ret;
> >> }
> >> --
> >> 2.20.1
> >>
> >> ___
> >> Alsa-devel mailing list
> >> alsa-de...@alsa-project.org
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.alsa-2Dproject.org_mailman_listinfo_alsa-2Ddevel=DwIBAg=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3GZ-_haXqY=g7GAQENVXx_RQdyXHInPMg=vETGQLSPeGb7K_ZsXv4Tl3VFfdXzyummTDga97ozJcg=LiW4SToh5U0zhnkox54oRhJ1u3vFNbBB9nmzRDuCDjI=
>
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Re: [PATCH 2/5] pidfd: add pidfd_wait()
On Fri, Jul 26, 2019 at 10:19:55AM +0200, Arnd Bergmann wrote:
> On Wed, Jul 24, 2019 at 4:47 PM Christian Brauner
> wrote:
>
> > +
> > +static int copy_rusage_to_user_any(struct rusage *kru, struct rusage
> > __user *ru)
> > +{
> > +#ifdef CONFIG_COMPAT
> > + if (in_compat_syscall())
> > + return put_compat_rusage(kru, (struct compat_rusage __user
> > *)ru);
> > +#endif
> > + return copy_to_user(ru, kru, sizeof(*kru));
> > +}
>
> I think this code needs a check for COMPAT_USE_64BIT_TIME in order
> to handle x32 correctly.
Similar to waitid(), indeed.
>
> It would be nice to introduce it in a separate patch, and then use it
> to kill off
> compat_sys_getrusage() and compat_sys_wait4(), and possibly even
> compat_sys_waitid() in combination with your copy_siginfo_to_user_any().
> That could be done as a cleanup patch afterwards, or as part of your series.
Right, but we won't go the syscall route but instead go the P_PIDFD
route for waitid(). :)
Christian
Re: [PATCH] tools/lib/traceevent, tools/perf: Move struct tep_handler definition in a local header file
Hi Andres,
On Fri, Jul 26, 2019 at 6:58 AM Andres Freund wrote:
>
> Hi,
>
...
>
> Is just plain wrong, as:
>
> > - return pevent->events[idx];
> > + return (all_events + idx);
>
> that's not a valid conversion. ->events isn't an array of tep_handle,
> it's an array of tep_handle* (and even if it were, the previous notation
> would have needed to dereference the value to make it comparable). What
> this does is look idx behind the individually allocated event. Which is
> incorrect.
>
You are right, it is a bug.
>
...
>
> The following patch fixes this for me. I can polish it up, but I'm
> wondering if I'm missing something here?
>
> diff --git i/tools/lib/traceevent/event-parse.h
> w/tools/lib/traceevent/event-parse.h
> index 642f68ab5fb2..7ebc9b5308d4 100644
> --- i/tools/lib/traceevent/event-parse.h
> +++ w/tools/lib/traceevent/event-parse.h
> @@ -517,6 +517,7 @@ int tep_read_number_field(struct tep_format_field *field,
> const void *data,
> unsigned long long *value);
>
> struct tep_event *tep_get_first_event(struct tep_handle *tep);
> +struct tep_event *tep_get_event(struct tep_handle *tep, int index);
> int tep_get_events_count(struct tep_handle *tep);
> struct tep_event *tep_find_event(struct tep_handle *tep, int id);
>
> diff --git i/tools/perf/util/trace-event-parse.c
> w/tools/perf/util/trace-event-parse.c
> index 62bc61155dd1..6a035ffd58ac 100644
> --- i/tools/perf/util/trace-event-parse.c
> +++ w/tools/perf/util/trace-event-parse.c
> @@ -179,28 +179,26 @@ struct tep_event *trace_find_next_event(struct
> tep_handle *pevent,
> {
> static int idx;
> int events_count;
> - struct tep_event *all_events;
>
> - all_events = tep_get_first_event(pevent);
> events_count = tep_get_events_count(pevent);
> - if (!pevent || !all_events || events_count < 1)
> + if (!pevent || events_count < 1)
> return NULL;
>
> if (!event) {
> idx = 0;
> - return all_events;
> + return tep_get_event(pevent, 0);
> }
>
> - if (idx < events_count && event == (all_events + idx)) {
> + if (idx < events_count && event == tep_get_event(pevent, idx)) {
> idx++;
> if (idx == events_count)
> return NULL;
> - return (all_events + idx);
> + return tep_get_event(pevent, idx);
> }
>
> for (idx = 1; idx < events_count; idx++) {
> - if (event == (all_events + (idx - 1)))
> - return (all_events + idx);
> + if (event == tep_get_event(pevent, idx - 1))
> + return tep_get_event(pevent, idx);
> }
> return NULL;
> }
>
>
I'm OK with the first part of the patch, the changes in
tools/lib/traceevent/event-parse.h.
tep_get_event() is an API and is omitted in the header by mistake, it
should be there.
As for the fix for the crash itself, I think it would be better to
implement your suggestion -
removing trace_find_next_event() at all and replacing it with
tep_get_events_count() and
tep_get_event() loop.
>
>
> Not related to this crash, but it also seems that the whole
> trace_find_next_event() API ought to be removed. Back when it was
>
> -struct event *trace_find_next_event(struct event *event)
> -{
> - if (!event)
> - return event_list;
> -
> - return event->next;
> -}
>
> it made some sense, but the changes in
>
> commit aaf045f72335653b24784d6042be8e4aee114403
> Author: Steven Rostedt
> Date: 2012-04-06 00:47:56 +0200
>
> perf: Have perf use the new libtraceevent.a library
>
> seem to make the current API somewhat absurd, as evidenced by the
> complexity in trace_find_next_event(). I mean even just removing that
> function and changing the two callsites to simple for loops with
> tep_get_events_count() & tep_get_event() ought to be a lot better.
>
> Greetings,
>
> Andres Freund
Thanks!
--
Tzvetomir (Ceco) Stoyanov
VMware Open Source Technology Center
[PATCH] isdn: mISDN: hfcsusb: Fix possible null-pointer dereferences in start_isoc_chain()
In start_isoc_chain(), usb_alloc_urb() on line 1392 may fail and return NULL. At this time, fifo->iso[i].urb is assigned to NULL. Then, fifo->iso[i].urb is used at some places, such as: LINE 1405:fill_isoc_urb(fifo->iso[i].urb, ...) urb->number_of_packets = num_packets; urb->transfer_flags = URB_ISO_ASAP; urb->actual_length = 0; urb->interval = interval; LINE 1416:fifo->iso[i].urb->... LINE 1419:fifo->iso[i].urb->... Thus, possible null-pointer dereferences may occur. To fix these bugs, "continue" is added to avoid using fifo->iso[i].urb when it is NULL. These bugs are found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- drivers/isdn/hardware/mISDN/hfcsusb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/isdn/hardware/mISDN/hfcsusb.c b/drivers/isdn/hardware/mISDN/hfcsusb.c index 0e224232f746..8fb7c5dea07f 100644 --- a/drivers/isdn/hardware/mISDN/hfcsusb.c +++ b/drivers/isdn/hardware/mISDN/hfcsusb.c @@ -1394,6 +1394,7 @@ start_isoc_chain(struct usb_fifo *fifo, int num_packets_per_urb, printk(KERN_DEBUG "%s: %s: alloc urb for fifo %i failed", hw->name, __func__, fifo->fifonum); + continue; } fifo->iso[i].owner_fifo = (struct usb_fifo *) fifo; fifo->iso[i].indx = i; -- 2.17.0
[PATCH 4/5] sched/deadline: Cleanup on_dl_rq() handling
Remove BUG_ON() in __enqueue_dl_entity() since there is already one in
enqueue_dl_entity().
Move the check that the dl_se is not on the dl_rq from
__dequeue_dl_entity() to dequeue_dl_entity() to align with the enqueue
side and use the on_dl_rq() helper function.
Signed-off-by: Dietmar Eggemann
---
kernel/sched/deadline.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 1fa005f79307..a9cb52ceb761 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1407,8 +1407,6 @@ static void __enqueue_dl_entity(struct sched_dl_entity
*dl_se)
struct sched_dl_entity *entry;
int leftmost = 1;
- BUG_ON(!RB_EMPTY_NODE(_se->rb_node));
-
while (*link) {
parent = *link;
entry = rb_entry(parent, struct sched_dl_entity, rb_node);
@@ -1430,9 +1428,6 @@ static void __dequeue_dl_entity(struct sched_dl_entity
*dl_se)
{
struct dl_rq *dl_rq = dl_rq_of_se(dl_se);
- if (RB_EMPTY_NODE(_se->rb_node))
- return;
-
rb_erase_cached(_se->rb_node, _rq->root);
RB_CLEAR_NODE(_se->rb_node);
@@ -1466,6 +1461,9 @@ enqueue_dl_entity(struct sched_dl_entity *dl_se,
static void dequeue_dl_entity(struct sched_dl_entity *dl_se)
{
+ if (!on_dl_rq(dl_se))
+ return;
+
__dequeue_dl_entity(dl_se);
}
--
2.17.1
[PATCH 5/5] sched/deadline: Use return value of SCHED_WARN_ON() in bw accounting
To make the decision whether to set rq or running bw to 0 in underflow case use the return value of SCHED_WARN_ON() rather than an extra if condition. Signed-off-by: Dietmar Eggemann --- kernel/sched/deadline.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index a9cb52ceb761..66c594b5507e 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -95,8 +95,7 @@ void __sub_running_bw(u64 dl_bw, struct dl_rq *dl_rq) lockdep_assert_held(&(rq_of_dl_rq(dl_rq))->lock); dl_rq->running_bw -= dl_bw; - SCHED_WARN_ON(dl_rq->running_bw > old); /* underflow */ - if (dl_rq->running_bw > old) + if (SCHED_WARN_ON(dl_rq->running_bw > old)) /* underflow */ dl_rq->running_bw = 0; /* kick cpufreq (see the comment in kernel/sched/sched.h). */ cpufreq_update_util(rq_of_dl_rq(dl_rq), 0); @@ -119,8 +118,7 @@ void __sub_rq_bw(u64 dl_bw, struct dl_rq *dl_rq) lockdep_assert_held(&(rq_of_dl_rq(dl_rq))->lock); dl_rq->this_bw -= dl_bw; - SCHED_WARN_ON(dl_rq->this_bw > old); /* underflow */ - if (dl_rq->this_bw > old) + if (SCHED_WARN_ON(dl_rq->this_bw > old)) /* underflow */ dl_rq->this_bw = 0; SCHED_WARN_ON(dl_rq->running_bw > dl_rq->this_bw); } -- 2.17.1
[PATCH 3/5] sched/deadline: Use __sub_running_bw() throughout dl_change_utilization()
dl_change_utilization() has a BUG_ON() to check that no schedutil
kthread (sugov) is entering this function. So instead of calling
sub_running_bw() which checks for the special entity related to a
sugov thread, call the underlying function __sub_running_bw().
Signed-off-by: Dietmar Eggemann
---
kernel/sched/deadline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 99d4c24a8637..1fa005f79307 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -164,7 +164,7 @@ void dl_change_utilization(struct task_struct *p, u64
new_bw)
rq = task_rq(p);
if (p->dl.dl_non_contending) {
- sub_running_bw(>dl, >dl);
+ __sub_running_bw(p->dl.dl_bw, >dl);
p->dl.dl_non_contending = 0;
/*
* If the timer handler is currently running and the
--
2.17.1
[PATCH 2/5] sched/deadline: Remove unused int flags from __dequeue_task_dl()
The int flags parameter is not used in __dequeue_task_dl(). Remove it.
Signed-off-by: Dietmar Eggemann
---
kernel/sched/deadline.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index d1aeada374e1..99d4c24a8637 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -637,7 +637,7 @@ static inline void deadline_queue_pull_task(struct rq *rq)
#endif /* CONFIG_SMP */
static void enqueue_task_dl(struct rq *rq, struct task_struct *p, int flags);
-static void __dequeue_task_dl(struct rq *rq, struct task_struct *p, int flags);
+static void __dequeue_task_dl(struct rq *rq, struct task_struct *p);
static void check_preempt_curr_dl(struct rq *rq, struct task_struct *p, int
flags);
/*
@@ -1245,7 +1245,7 @@ static void update_curr_dl(struct rq *rq)
(dl_se->flags & SCHED_FLAG_DL_OVERRUN))
dl_se->dl_overrun = 1;
- __dequeue_task_dl(rq, curr, 0);
+ __dequeue_task_dl(rq, curr);
if (unlikely(dl_se->dl_boosted || !start_dl_timer(curr)))
enqueue_task_dl(rq, curr, ENQUEUE_REPLENISH);
@@ -1535,7 +1535,7 @@ static void enqueue_task_dl(struct rq *rq, struct
task_struct *p, int flags)
enqueue_pushable_dl_task(rq, p);
}
-static void __dequeue_task_dl(struct rq *rq, struct task_struct *p, int flags)
+static void __dequeue_task_dl(struct rq *rq, struct task_struct *p)
{
dequeue_dl_entity(>dl);
dequeue_pushable_dl_task(rq, p);
@@ -1544,7 +1544,7 @@ static void __dequeue_task_dl(struct rq *rq, struct
task_struct *p, int flags)
static void dequeue_task_dl(struct rq *rq, struct task_struct *p, int flags)
{
update_curr_dl(rq);
- __dequeue_task_dl(rq, p, flags);
+ __dequeue_task_dl(rq, p);
if (p->on_rq == TASK_ON_RQ_MIGRATING || flags & DEQUEUE_SAVE) {
sub_running_bw(>dl, >dl);
--
2.17.1
