Re: [PATCH v7 2/2] ARM: ftrace: Add MODULE_PLTS support
Hi!
On 07/03/2021 18:26, Qais Yousef wrote:
> I tried on 5.12-rc2 and 5.11 but couldn't reproduce the problem using your
> instructions on the other email. But most likely because I'm hitting another
> problem that could be masking it. I'm not sure it is related or just randomly
> happened to hit it.
>
> Did you see something similar?
[...]
> [0.00] [] (ftrace_bug) from []
> (ftrace_process_locs+0x2b0/0x518)
> [0.00] r7:c3817ac4 r6:c38040c0 r5:0a3c r4:000134e4
> [0.00] [] (ftrace_process_locs) from []
> (ftrace_init+0xc8/0x174)
> [0.00] r10:c2ffa000 r9:c2be8a78 r8:c2c5d1fc r7:c2c0c208
> r6:0001 r5:c2d0908c
> [0.00] r4:c362f518
> [0.00] [] (ftrace_init) from []
> (start_kernel+0x2f4/0x5b8)
> [0.00] r9:c2be8a78 r8:dbfffec0 r7: r6:c36385cc
> r5:c2d08f00 r4:c2ffa000
> [0.00] [] (start_kernel) from [<>] (0x0)
This means, FTRACE has more problems with your kernel/compiler/platform, I've
addressed similar issue
in the past, but my patch should be long merged:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1817963.html
Could it be the same problem as here:
https://www.spinics.net/lists/arm-kernel/msg854022.html
Seems that the size check deserves something line BUILD_BUG_ON() with FTRACE...
>> diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c
>> index 9a79ef6..fa867a5 100644
>> --- a/arch/arm/kernel/ftrace.c
>> +++ b/arch/arm/kernel/ftrace.c
>> @@ -70,6 +70,19 @@ int ftrace_arch_code_modify_post_process(void)
>>
>> static unsigned long ftrace_call_replace(unsigned long pc, unsigned long
>> addr)
>> {
>> +s32 offset = addr - pc;
>> +s32 blim = 0xfe08;
>> +s32 flim = 0x0204;
>
> This look like magic numbers to me..
These magic numbers are most probably the reason for your FTRACE to resign...
Those are backward- and forward-branch limits. I didn't find the matching
DEFINEs
in the kernel, but I would be happy to learn them. I can also put some comments,
but I actually thought the purpose would be obvious from the code...
>> +
>> +if (IS_ENABLED(CONFIG_THUMB2_KERNEL)) {
>> +blim = 0xff04;
>> +flim = 0x0102;
>
> .. ditto ..
>
>> +}
>> +
>> +if (IS_ENABLED(CONFIG_ARM_MODULE_PLTS) &&
>> +(offset < blim || offset > flim))
>> +return 0;
>
> .. I could have missed something, but wouldn't something like below be
> clearer?
> Only compile tested. I think abs() will do the right thing here given the
> passed types. I admit I don't understand why you have the '4' and '8' at the
> lowest nibble..
Yes, the limits are not symmetrical. These "magic numbers" have been checked
many
times by me, but I admit I'm not expert in ARM assembly. I'm however still quite
sure about them.
> diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c
> index fa867a57100f..b44aee87c53a 100644
> --- a/arch/arm/kernel/ftrace.c
> +++ b/arch/arm/kernel/ftrace.c
> @@ -70,17 +70,13 @@ int ftrace_arch_code_modify_post_process(void)
>
>static unsigned long ftrace_call_replace(unsigned long pc, unsigned
> long addr)
>{
> - s32 offset = addr - pc;
> - s32 blim = 0xfe08;
> - s32 flim = 0x0204;
> + u32 offset = abs(addr - pc);
> + u32 range = 0x0200; /* +-32MiB */
>
> - if (IS_ENABLED(CONFIG_THUMB2_KERNEL)) {
> - blim = 0xff04;
> - flim = 0x0102;
> - }
> + if (IS_ENABLED(CONFIG_THUMB2_KERNEL))
> + range = 0x0100; /* +-16MiB */
>
> - if (IS_ENABLED(CONFIG_ARM_MODULE_PLTS) &&
> - (offset < blim || offset > flim))
> + if (IS_ENABLED(CONFIG_ARM_MODULE_PLTS) && offset > range)
> return 0;
See above, the limits are not symmetrical.
> return arm_gen_branch_link(pc, addr);
>
> In case CONFIG_ARM_MODULE_PLTS is not enabled what would happen? Is it
> impossible to hit this corner case or we could fail one way or another? IOW,
> should this check be always compiled in?
I didn't want to modify the original behavior and the limits are again checked
in either ARM or THUMB implementations of __arm_gen_branch() (there you will
again find a nice set of "magic numbers".
>> +
>> return arm_gen_branch_link(pc, addr);
>> }
>>
>> @@ -124,10 +137,22 @@ int ftrace_make_call(struct dyn_ftrace *rec, unsigned
>> long addr)
>> {
>> unsigned long new, old;
>> unsigned long ip = rec->ip;
>> +unsigned long aaddr = adjust_address(rec, addr);
>>
>> old = ftrace_nop_replace(rec);
>>
>> -new = ftrace_call_replace(ip, adjust_address(rec, addr));
>> +new = ftrace_call_replace(ip, aaddr);
>> +
>> +#ifdef CONFIG_ARM_MODULE_PLTS
>> +if (!new) {
>> +
Re: [PATCH] staging: rtl8192e: Fix possible buffer overflow in _rtl92e_wx_set_scan
On Fri, Mar 05, 2021 at 03:00:14PM +, Lee wrote:
>
> Hi Dan,
>
> Do you think any of these could be potential issues:
>
> driver/staging/
>
> rtl8192e/rtllib_rx.c:2442
memcpy(dst->ssid, src->ssid, src->ssid_len);
Smatch says that at this point we know "src->ssid_len" is in the 1-32
range. This is without any fixes to how Smatch parses nl_len().
> wlan-ng/cfg80211.c:316
313 if (request->n_ssids > 0) {
314 msg1.scantype.data = P80211ENUM_scantype_active;
315 msg1.ssid.data.len = request->ssids->ssid_len;
316 memcpy(msg1.ssid.data.data,
317 request->ssids->ssid, request->ssids->ssid_len);
318 } else {
The only thing Smatch knows about "request->ssids->ssid_len" is that
it's 0-255. I had not marked "msg1.ssid.data.data" as a protected
struct member so it didn't generate a warning.
I think cfg80211_scan_request structs are filled out in a systematic
way in ieee80211_request_ibss_scan() and they're bounds checked properly
so this isn't a bug.
> rtl8723bs/os_dep/ioctl_cfg80211.c:1591
> rtl8723bs/os_dep/ioctl_cfg80211.c:2738
Same.
regards,
dan carpenter
linux-next: error fetching the arm-soc-fixes tree
Hi all, Fetching the arm-soc-fixes tree (git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git#arm/fixes) produces this error: fatal: couldn't find remote ref refs/heads/arm/fixes -- Cheers, Stephen Rothwell pgpD1vPOkV3z3.pgp Description: OpenPGP digital signature
[PATCH] docs/kokr: make sections on bug reporting match practice
From: SeongJae Park
Translate this commit to Korean:
cf6d6fc27936 ("docs: process/howto.rst: make sections on bug reporting
match practice")
Signed-off-by: SeongJae Park
---
Documentation/translations/ko_KR/howto.rst | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/translations/ko_KR/howto.rst
b/Documentation/translations/ko_KR/howto.rst
index 787f1e85f8a0..a2bdd564c907 100644
--- a/Documentation/translations/ko_KR/howto.rst
+++ b/Documentation/translations/ko_KR/howto.rst
@@ -339,14 +339,8 @@ Andrew Morton의 글이 있다.
버그 보고
-
-https://bugzilla.kernel.org 는 리눅스 커널 개발자들이 커널의 버그를 추적하는
-곳이다. 사용자들은 발견한 모든 버그들을 보고하기 위하여 이 툴을 사용할 것을
-권장한다. kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라.
-
-https://bugzilla.kernel.org/page.cgi?id=faq.html
-
메인 커널 소스 디렉토리에 있는 'Documentation/admin-guide/reporting-issues.rst'
-파일은 커널 버그라고 생각되는 것을 보고하는 방법에 관한 좋은 템플릿이며 문제를
+파일은 커널 버그라고 생각되는 것을 어떻게 보고하면 되는지, 그리고 문제를
추적하기 위해서 커널 개발자들이 필요로 하는 정보가 무엇들인지를 상세히 설명하고
있다.
@@ -362,8 +356,14 @@ https://bugzilla.kernel.org 는 리눅스 커널 개발자들이 커널의 버
점수를 얻을 수 있는 가장 좋은 방법중의 하나이다. 왜냐하면 많은 사람들은
다른 사람들의 버그들을 수정하기 위하여 시간을 낭비하지 않기 때문이다.
-이미 보고된 버그 리포트들을 가지고 작업하기 위해서 https://bugzilla.kernel.org
-를 참조하라.
+이미 보고된 버그 리포트들을 가지고 작업하기 위해서는 여러분이 관심있는
+서브시스템을 찾아라. 해당 서브시스템의 버그들이 어디로 리포트 되는지
+MAINTAINERS 파일을 체크하라; 그건 대부분 메일링 리스트이고, 가끔은 버그 추적
+시스템이다. 그 장소에 있는 최근 버그 리포트 기록들을 검색하고 여러분이 보기에
+적합하다 싶은 것을 도와라. 여러분은 버그 리포트를 위해
+https://bugzilla.kernel.org 를 체크하고자 할 수도 있다; 소수의 커널
+서브시스템들만이 버그 신고와 추적을 위해 해당 시스템을 실제로 사용하고 있지만,
+전체 커널의 버그들이 그곳에 정리된다.
메일링 리스트들
--
2.17.1
Re: [PATCH 1/1] RISC-V: correct enum sbi_ext_rfence_fid
On Sat, Mar 6, 2021 at 4:12 AM Anup Patel wrote:
>
> On Sat, Mar 6, 2021 at 11:19 AM Heinrich Schuchardt
> wrote:
> >
> > The constants in enum sbi_ext_rfence_fid should match the SBI
> > specification. See
> > https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc#78-function-listing
> >
> > | Function Name | FID | EID
> > | sbi_remote_fence_i | 0 | 0x52464E43
> > | sbi_remote_sfence_vma | 1 | 0x52464E43
> > | sbi_remote_sfence_vma_asid | 2 | 0x52464E43
> > | sbi_remote_hfence_gvma_vmid | 3 | 0x52464E43
> > | sbi_remote_hfence_gvma | 4 | 0x52464E43
> > | sbi_remote_hfence_vvma_asid | 5 | 0x52464E43
> > | sbi_remote_hfence_vvma | 6 | 0x52464E43
> >
> > Fixes: ecbacc2a3efd ("RISC-V: Add SBI v0.2 extension definitions")
> > Reported-by: Sean Anderson
> > Signed-off-by: Heinrich Schuchardt
>
> Good catch.
>
> I guess we never saw any issues because these calls are only used by
> KVM RISC-V which is not merged yet. Further for KVM RISC-V, the HFENCE
> instruction is emulated as flush everything on FPGA, QEMU, and Spike so
> we did not notice any issue with KVM RISC-V too.
>
OpenSBI & Xvisor also define the same order as Linux kernel. The
existing order(in Linux kernel)
makes more sense w.r.to Lexicographic order as well.
Should we just fix the spec instead ?
> Looks good to me.
>
> Reviewed-by: Anup Patel
>
> Regards,
> Anup
>
> > ---
> > arch/riscv/include/asm/sbi.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
> > index 99895d9c3bdd..d7027411dde8 100644
> > --- a/arch/riscv/include/asm/sbi.h
> > +++ b/arch/riscv/include/asm/sbi.h
> > @@ -51,10 +51,10 @@ enum sbi_ext_rfence_fid {
> > SBI_EXT_RFENCE_REMOTE_FENCE_I = 0,
> > SBI_EXT_RFENCE_REMOTE_SFENCE_VMA,
> > SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID,
> > - SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
> > SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA_VMID,
> > - SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA,
> > + SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
> > SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA_ASID,
> > + SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA,
> > };
> >
> > enum sbi_ext_hsm_fid {
> > --
> > 2.30.1
> >
> >
> > ___
> > linux-riscv mailing list
> > linux-ri...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
--
Regards,
Atish
Re: [PATCH v3 1/3] KVM: nVMX: Sync L2 guest CET states between L1/L2
On Thu, Mar 04, 2021 at 08:46:45AM -0800, Sean Christopherson wrote:
> On Thu, Mar 04, 2021, Yang Weijiang wrote:
> > @@ -3375,6 +3391,12 @@ enum nvmx_vmentry_status
> > nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu,
> > if (kvm_mpx_supported() &&
> > !(vmcs12->vm_entry_controls & VM_ENTRY_LOAD_BNDCFGS))
> > vmx->nested.vmcs01_guest_bndcfgs = vmcs_read64(GUEST_BNDCFGS);
> > + if (kvm_cet_supported() &&
> > + !(vmcs12->vm_entry_controls & VM_ENTRY_LOAD_CET_STATE)) {
>
> Alignment.
>
> > + vmx->nested.vmcs01_guest_ssp = vmcs_readl(GUEST_SSP);
> > + vmx->nested.vmcs01_guest_s_cet = vmcs_readl(GUEST_S_CET);
> > + vmx->nested.vmcs01_guest_ssp_tbl =
> > vmcs_readl(GUEST_INTR_SSP_TABLE);
> > + }
> >
> > /*
> > * Overwrite vmcs01.GUEST_CR3 with L1's CR3 if EPT is disabled *and*
> > @@ -4001,6 +4023,9 @@ static bool is_vmcs12_ext_field(unsigned long field)
> > case GUEST_IDTR_BASE:
> > case GUEST_PENDING_DBG_EXCEPTIONS:
> > case GUEST_BNDCFGS:
> > + case GUEST_SSP:
> > + case GUEST_INTR_SSP_TABLE:
> > + case GUEST_S_CET:
> > return true;
> > default:
> > break;
> > @@ -4052,6 +4077,11 @@ static void sync_vmcs02_to_vmcs12_rare(struct
> > kvm_vcpu *vcpu,
> > vmcs_readl(GUEST_PENDING_DBG_EXCEPTIONS);
> > if (kvm_mpx_supported())
> > vmcs12->guest_bndcfgs = vmcs_read64(GUEST_BNDCFGS);
> > + if (kvm_cet_supported()) {
>
> Isn't the existing kvm_mpx_supported() check wrong in the sense that KVM only
> needs to sync to vmcs12 if KVM and the guest both support MPX?
For MPX, if guest_cpuid_has() is not efficent, can it be checked by BNDCFGS EN
bit?
E.g.:
if (kvm_mpx_supported() && (vmcs12->guest_bndcfgs & 1))
> Same would apply to CET. Not sure it'd be a net positive in terms of
> performance since
> guest_cpuid_has() can be quite slow, but overwriting vmcs12 fields that
> technically don't exist
> feels wrong.
For CET, can we get equivalent effect by checking vmcs12->guest_cr4.CET?
E.g.:
if (kvm_cet_supported() && (vmcs12->guest_cr4 & X86_CR4_CET))
>
> > + vmcs12->guest_ssp = vmcs_readl(GUEST_SSP);
> > + vmcs12->guest_s_cet = vmcs_readl(GUEST_S_CET);
> > + vmcs12->guest_ssp_tbl = vmcs_readl(GUEST_INTR_SSP_TABLE);
> > + }
> >
> > vmx->nested.need_sync_vmcs02_to_vmcs12_rare = false;
> > }
> > diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
> > index 9d3a557949ac..36dc4fdb0909 100644
> > --- a/arch/x86/kvm/vmx/vmx.h
> > +++ b/arch/x86/kvm/vmx/vmx.h
> > @@ -155,6 +155,9 @@ struct nested_vmx {
> > /* to migrate it to L2 if VM_ENTRY_LOAD_DEBUG_CONTROLS is off */
> > u64 vmcs01_debugctl;
> > u64 vmcs01_guest_bndcfgs;
> > + u64 vmcs01_guest_ssp;
> > + u64 vmcs01_guest_s_cet;
> > + u64 vmcs01_guest_ssp_tbl;
> >
> > /* to migrate it to L1 if L2 writes to L1's CR8 directly */
> > int l1_tpr_threshold;
> > --
> > 2.26.2
> >
RE: [PATCH] usb: cdnsp: Fixes incorrect value in ISOC TRB
You have right. It's the operator priority issue.
I've made this condition as separate "if" statement as suggested by Greg.
V2 has been posted.
Pawel
>
>
>On 21-03-05 06:10:59, Pawel Laszczak wrote:
>> From: Pawel Laszczak
>>
>> The value "start_cycle ? 0 : 1" in assignment caused
>> implicit truncation whole value to 1 byte.
>> To fix the issue, an explicit casting has been added.
>
>The root cause for this issue should be operator "|" priority higher
>than "? :", I think just add () for start_cycle ? 0 : 1 could fix it.
>Please double confirm it, and change the commit log if necessary
>
>Peter
>>
>> Fixes: commit 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence
>> USBSSP DRD Driver")
>> Signed-off-by: Pawel Laszczak
>> ---
>> drivers/usb/cdns3/cdnsp-ring.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/cdns3/cdnsp-ring.c b/drivers/usb/cdns3/cdnsp-ring.c
>> index f9170d177a89..d35bc4490216 100644
>> --- a/drivers/usb/cdns3/cdnsp-ring.c
>> +++ b/drivers/usb/cdns3/cdnsp-ring.c
>> @@ -2197,7 +2197,7 @@ static int cdnsp_queue_isoc_tx(struct cdnsp_device
>> *pdev,
>> * inverted in the first TDs isoc TRB.
>> */
>> field = TRB_TYPE(TRB_ISOC) | TRB_TLBPC(last_burst_pkt) |
>> -start_cycle ? 0 : 1 | TRB_SIA | TRB_TBC(burst_count);
>> +(u32)(start_cycle ? 0 : 1) | TRB_SIA | TRB_TBC(burst_count);
>>
>> /* Fill the rest of the TRB fields, and remaining normal TRBs. */
>> for (i = 0; i < trbs_per_td; i++) {
>> --
>> 2.25.1
>>
--
Thanks,
Pawel Laszczak
Re: [PATCH v2] usb: cdnsp: Fixes incorrect value in ISOC TRB
On Mon, Mar 08, 2021 at 08:31:03AM +0100, Pawel Laszczak wrote:
> From: Pawel Laszczak
>
> Fixes issue with priority of operator. Operator "|" priority is
> higher then "? :".
> To improve the readability the operator "? :" has been replaced with
> "if ()" statement.
>
> Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD
> Driver")
> Signed-off-by: Pawel Laszczak
>
> ---
> Changelog:
> v2:
> - changed the commit log
> - added separate "if" statement to improve readability
>
> drivers/usb/cdns3/cdnsp-ring.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/cdns3/cdnsp-ring.c b/drivers/usb/cdns3/cdnsp-ring.c
> index e15e13ba27dc..b23f09a68427 100644
> --- a/drivers/usb/cdns3/cdnsp-ring.c
> +++ b/drivers/usb/cdns3/cdnsp-ring.c
> @@ -2198,7 +2198,10 @@ static int cdnsp_queue_isoc_tx(struct cdnsp_device
> *pdev,
>* inverted in the first TDs isoc TRB.
>*/
> field = TRB_TYPE(TRB_ISOC) | TRB_TLBPC(last_burst_pkt) |
> - start_cycle ? 0 : 1 | TRB_SIA | TRB_TBC(burst_count);
> + TRB_SIA | TRB_TBC(burst_count);
> +
> + if (!start_cycle)
> + field |= TRB_CYCLE;
Thank you for the change:
Reviewed-by: Greg Kroah-Hartman
Re: [PATCH 4/6] usbip: fix stub_dev usbip_sockfd_store() races leading to gpf
On 2021/03/08 12:53, Shuah Khan wrote:
> Fix the above problems:
> - Stop using kthread_get_run() macro to create/start threads.
> - Create threads and get task struct reference.
> - Add kthread_create() failure handling and bail out.
> - Hold usbip_device lock to update local and shared states after
> creating rx and tx threads.
> - Update usbip_device status to SDEV_ST_USED.
> - Update usbip_device tcp_socket, sockfd, tcp_rx, and tcp_tx
> - Start threads after usbip_device (tcp_socket, sockfd, tcp_rx, tcp_tx,
> and status) is complete.
No, the whole usbip_sockfd_store() etc. should be serialized using a mutex,
for two different threads can open same file and write the same content at
the same moment. This results in seeing SDEV_ST_AVAILABLE and creating two
threads and overwiting global variables and setting SDEV_ST_USED and starting
two threads by each of two thread, which will later fail to call kthread_stop()
on one of two thread because global variables are overwritten.
kthread_crate() (which involves GFP_KERNEL allocation) can take long time
enough to hit
usbip_sockfd_store() must perform
if (sdev->ud.status != SDEV_ST_AVAILABLE) {
/* misc assignments for attach operation */
sdev->ud.status = SDEV_ST_USED;
}
under a lock, or multiple ud->tcp_{tx,rx} are created (which will later
cause a crash like [1]) and refcount on ud->tcp_socket is leaked when
usbip_sockfd_store() is concurrently called.
problem. That's why my patch introduced usbip_event_mutex lock.
Re: [PATCH v6 36/37] firmware: arm_scmi: add protocol modularization support
On Tue, Feb 02, 2021 at 10:15:54PM +, Cristian Marussi wrote: > Extend SCMI protocols accounting mechanism to address possible module > usage and add the support to possibly define new protocols as loadable > modules. > > Keep Standard protocols built into the SCMI core. > The changes look good, however without any users I am bit hesitant to add this yet. However if you think it is hard to maintain it outside the tree until first user gets merged, we can merge provided we test this every release. Let me know your thoughts. Also any comment from users requesting this would be useful. -- Regards, Sudeep
[PATCH v2] usb: cdnsp: Fixes incorrect value in ISOC TRB
From: Pawel Laszczak
Fixes issue with priority of operator. Operator "|" priority is
higher then "? :".
To improve the readability the operator "? :" has been replaced with
"if ()" statement.
Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD
Driver")
Signed-off-by: Pawel Laszczak
---
Changelog:
v2:
- changed the commit log
- added separate "if" statement to improve readability
drivers/usb/cdns3/cdnsp-ring.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/cdns3/cdnsp-ring.c b/drivers/usb/cdns3/cdnsp-ring.c
index e15e13ba27dc..b23f09a68427 100644
--- a/drivers/usb/cdns3/cdnsp-ring.c
+++ b/drivers/usb/cdns3/cdnsp-ring.c
@@ -2198,7 +2198,10 @@ static int cdnsp_queue_isoc_tx(struct cdnsp_device *pdev,
* inverted in the first TDs isoc TRB.
*/
field = TRB_TYPE(TRB_ISOC) | TRB_TLBPC(last_burst_pkt) |
- start_cycle ? 0 : 1 | TRB_SIA | TRB_TBC(burst_count);
+ TRB_SIA | TRB_TBC(burst_count);
+
+ if (!start_cycle)
+ field |= TRB_CYCLE;
/* Fill the rest of the TRB fields, and remaining normal TRBs. */
for (i = 0; i < trbs_per_td; i++) {
--
2.25.1
[PATCH] coccinelle: misc: update uninitialized_var.cocci documentation
Remove the documentation link from the warning message because commit
3942ea7a10c9 ("deprecated.rst: Remove now removed uninitialized_var")
removed the section from documentation. Update the rule documentation
accordingly.
Signed-off-by: Denis Efremov
---
scripts/coccinelle/misc/uninitialized_var.cocci | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/scripts/coccinelle/misc/uninitialized_var.cocci
b/scripts/coccinelle/misc/uninitialized_var.cocci
index 8fa845cefe11..69bbaae47e73 100644
--- a/scripts/coccinelle/misc/uninitialized_var.cocci
+++ b/scripts/coccinelle/misc/uninitialized_var.cocci
@@ -1,7 +1,9 @@
// SPDX-License-Identifier: GPL-2.0-only
///
/// Please, don't reintroduce uninitialized_var().
-/// From Documentation/process/deprecated.rst:
+///
+/// From Documentation/process/deprecated.rst,
+/// commit 4b19bec97c88 ("docs: deprecated.rst: Add uninitialized_var()"):
/// For any compiler warnings about uninitialized variables, just add
/// an initializer. Using warning-silencing tricks is dangerous as it
/// papers over real bugs (or can in the future), and suppresses unrelated
@@ -11,6 +13,11 @@
/// obviously redundant, the compiler's dead-store elimination pass will make
/// sure there are no needless variable writes.
///
+/// Later, commit 3942ea7a10c9 ("deprecated.rst: Remove now removed
+/// uninitialized_var") removed this section because all initializations of
+/// this kind were cleaned-up from the kernel. This cocci rule checks that
+/// the macro is not explicitly or implicitly reintroduced.
+///
// Confidence: High
// Copyright: (C) 2020 Denis Efremov ISPRAS
// Options: --no-includes --include-headers
@@ -40,12 +47,10 @@ position p;
p << r.p;
@@
-coccilib.report.print_report(p[0],
- "WARNING this kind of initialization is deprecated
(https://www.kernel.org/doc/html/latest/process/deprecated.html#uninitialized-var)")
+coccilib.report.print_report(p[0], "WARNING this kind of initialization is
deprecated")
@script:python depends on org@
p << r.p;
@@
-coccilib.org.print_todo(p[0],
- "WARNING this kind of initialization is deprecated
(https://www.kernel.org/doc/html/latest/process/deprecated.html#uninitialized-var)")
+coccilib.org.print_todo(p[0], "WARNING this kind of initialization is
deprecated")
--
2.26.2
Re: [PATCH v2] iio: buffer: fix use-after-free for attached_buffers array
On Sun, Mar 7, 2021 at 8:55 PM Alexandru Ardelean
wrote:
>
> Thanks to Lars for finding this.
> The free of the 'attached_buffers' array should be done as late as
> possible. This change moves it to iio_buffers_put(), which looks like
> the best place for it, since it takes place right before the IIO device
> data is free'd.
> The free of this array will be handled by calling iio_device_free().
> The iio_buffers_put() function is renamed to iio_device_detach_buffers()
> since the role of this function changes a bit.
>
> It looks like this issue was ocurring on the error path of
> iio_buffers_alloc_sysfs_and_mask() and in
> iio_buffers_free_sysfs_and_mask()
>
> Added a comment in the doc-header of iio_device_attach_buffer() to
> mention how this will be free'd in case anyone is reading the code
> and becoming confused about it.
>
> Fixes: 36f3118c414d ("iio: buffer: introduce support for attaching more IIO
> buffers")
> Reported-by: Lars-Peter Clausen
> Signed-off-by: Alexandru Ardelean
> ---
Forgot the changelog.
Changelog v1 -> v2:
* rename iio_buffers_put() -> iio_device_detach_buffers()
> drivers/iio/iio_core.h| 4 ++--
> drivers/iio/industrialio-buffer.c | 9 +
> drivers/iio/industrialio-core.c | 2 +-
> 3 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iio/iio_core.h b/drivers/iio/iio_core.h
> index 062fe16c6c49..8f4a9b264962 100644
> --- a/drivers/iio/iio_core.h
> +++ b/drivers/iio/iio_core.h
> @@ -77,7 +77,7 @@ void iio_buffers_free_sysfs_and_mask(struct iio_dev
> *indio_dev);
>
> void iio_disable_all_buffers(struct iio_dev *indio_dev);
> void iio_buffer_wakeup_poll(struct iio_dev *indio_dev);
> -void iio_buffers_put(struct iio_dev *indio_dev);
> +void iio_device_detach_buffers(struct iio_dev *indio_dev);
>
> #else
>
> @@ -93,7 +93,7 @@ static inline void iio_buffers_free_sysfs_and_mask(struct
> iio_dev *indio_dev) {}
>
> static inline void iio_disable_all_buffers(struct iio_dev *indio_dev) {}
> static inline void iio_buffer_wakeup_poll(struct iio_dev *indio_dev) {}
> -static inline void iio_buffers_put(struct iio_dev *indio_dev) {}
> +static inline void iio_device_detach_buffers(struct iio_dev *indio_dev) {}
>
> #endif
>
> diff --git a/drivers/iio/industrialio-buffer.c
> b/drivers/iio/industrialio-buffer.c
> index 1a415e97174e..1ff7f731b044 100644
> --- a/drivers/iio/industrialio-buffer.c
> +++ b/drivers/iio/industrialio-buffer.c
> @@ -326,7 +326,7 @@ void iio_buffer_init(struct iio_buffer *buffer)
> }
> EXPORT_SYMBOL(iio_buffer_init);
>
> -void iio_buffers_put(struct iio_dev *indio_dev)
> +void iio_device_detach_buffers(struct iio_dev *indio_dev)
> {
> struct iio_dev_opaque *iio_dev_opaque = to_iio_dev_opaque(indio_dev);
> struct iio_buffer *buffer;
> @@ -336,6 +336,8 @@ void iio_buffers_put(struct iio_dev *indio_dev)
> buffer = iio_dev_opaque->attached_buffers[i];
> iio_buffer_put(buffer);
> }
> +
> + kfree(iio_dev_opaque->attached_buffers);
> }
>
> static ssize_t iio_show_scan_index(struct device *dev,
> @@ -1764,7 +1766,6 @@ int iio_buffers_alloc_sysfs_and_mask(struct iio_dev
> *indio_dev)
> buffer = iio_dev_opaque->attached_buffers[unwind_idx];
> __iio_buffer_free_sysfs_and_mask(buffer);
> }
> - kfree(iio_dev_opaque->attached_buffers);
> return ret;
> }
>
> @@ -1786,8 +1787,6 @@ void iio_buffers_free_sysfs_and_mask(struct iio_dev
> *indio_dev)
> buffer = iio_dev_opaque->attached_buffers[i];
> __iio_buffer_free_sysfs_and_mask(buffer);
> }
> -
> - kfree(iio_dev_opaque->attached_buffers);
> }
>
> /**
> @@ -2062,6 +2061,8 @@ static int iio_buffer_mmap(struct file *filep, struct
> vm_area_struct *vma)
> * This function attaches a buffer to a IIO device. The buffer stays
> attached to
> * the device until the device is freed. For legacy reasons, the first
> attached
> * buffer will also be assigned to 'indio_dev->buffer'.
> + * The array allocated here, will be free'd via the
> iio_device_detach_buffers()
> + * call which is handled by the iio_device_free().
> */
> int iio_device_attach_buffer(struct iio_dev *indio_dev,
> struct iio_buffer *buffer)
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index d74fbac908df..3be5f75c2846 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -1587,7 +1587,7 @@ static void iio_dev_release(struct device *device)
> iio_device_unregister_eventset(indio_dev);
> iio_device_unregister_sysfs(indio_dev);
>
> - iio_buffers_put(indio_dev);
> + iio_device_detach_buffers(indio_dev);
>
> ida_simple_remove(_ida, indio_dev->id);
> kfree(iio_dev_opaque);
> --
> 2.25.1
>
Re: [PATCH v3] amba: Remove deferred device addition
Hi Saravana, On 05.03.2021 19:02, Saravana Kannan wrote: > On Fri, Mar 5, 2021 at 3:45 AM Marek Szyprowski > wrote: >> On 04.03.2021 20:51, Saravana Kannan wrote: >>> The uevents generated for an amba device need PID and CID information >>> that's available only when the amba device is powered on, clocked and >>> out of reset. So, if those resources aren't available, the information >>> can't be read to generate the uevents. To workaround this requirement, >>> if the resources weren't available, the device addition was deferred and >>> retried periodically. >>> >>> However, this deferred addition retry isn't based on resources becoming >>> available. Instead, it's retried every 5 seconds and causes arbitrary >>> probe delays for amba devices and their consumers. >>> >>> Also, maintaining a separate deferred-probe like mechanism is >>> maintenance headache. >>> >>> With this commit, instead of deferring the device addition, we simply >>> defer the generation of uevents for the device and probing of the device >>> (because drivers needs PID and CID to match) until the PID and CID >>> information can be read. This allows us to delete all the amba specific >>> deferring code and also avoid the arbitrary probing delays. >>> >>> Cc: Rob Herring >>> Cc: Ulf Hansson >>> Cc: John Stultz >>> Cc: Saravana Kannan >>> Cc: Linus Walleij >>> Cc: Sudeep Holla >>> Cc: Nicolas Saenz Julienne >>> Cc: Geert Uytterhoeven >>> Cc: Marek Szyprowski >>> Cc: Russell King >>> Signed-off-by: Saravana Kannan >>> --- >>> >>> v1 -> v2: >>> - Dropped RFC tag >>> - Complete rewrite to not use stub devices. >>> v2 -> v3: >>> - Flipped the if() condition for hard-coded periphids. >>> - Added a stub driver to handle the case where all amba drivers are >>> modules loaded by uevents. >>> - Cc Marek after I realized I forgot to add him. >>> >>> Marek, >>> >>> Would you mind testing this? It looks okay with my limited testing. >> It looks it works fine on my test systems. I've checked current >> linux-next and this patch. You can add: >> >> Tested-by: Marek Szyprowski > Hi Marek, > > Thanks! Does your test set up have amda drivers that are loaded based > on uevents? That's the one I couldn't test. I've checked both, the built-in and all amba drivers compiled as modules, loaded by udev. Both works fine here. >> I've briefly scanned the code and I'm curious how does it work. Does it >> depend on the recently introduced "fw_devlink=on" feature? I don't see >> other mechanism, which would trigger matching amba device if pm domains, >> clocks or resets were not available on time to read pid/cid while adding >> a device... > No, it does not depend on fw_devlink or device links in any way. > > When a device is attempted to be probed (when it's added or during > deferred probe), it's matched with all the drivers on the bus. > When a new driver is registered to a bus, all devices in that bus are > matched with the driver to see if they'll work together. > That's how match is called. And match() can return -EPROBE_DEFER and > that'll cause the device to be put in the deferred probe list by > driver core. > > The tricky part in this patch was the uevent handling and the > chicken-and-egg issue I talk about in the comments. Thanks for the explanation. This EPROBE_DEFER support in match() callback must be something added after I crafted that periodic retry based workaround. Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
[PATCH] ASoC: bcm: add missing call to of_node_put()
In one of the error paths of the for_each_child_of_node() loop,
add missing call to of_node_put().
Fix the following coccicheck warning:
./sound/soc/bcm/cygnus-ssp.c:1346:1-33: WARNING: Function
"for_each_available_child_of_node" should have of_node_put() before
return around line 1352.
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
sound/soc/bcm/cygnus-ssp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/sound/soc/bcm/cygnus-ssp.c b/sound/soc/bcm/cygnus-ssp.c
index 6e634b4..aa16a23 100644
--- a/sound/soc/bcm/cygnus-ssp.c
+++ b/sound/soc/bcm/cygnus-ssp.c
@@ -1348,8 +1348,10 @@ static int cygnus_ssp_probe(struct platform_device *pdev)
_ssp_dai[active_port_count]);
/* negative is err, 0 is active and good, 1 is disabled */
- if (err < 0)
+ if (err < 0) {
+ of_node_put(child_node);
return err;
+ }
else if (!err) {
dev_dbg(dev, "Activating DAI: %s\n",
cygnus_ssp_dai[active_port_count].name);
--
1.8.3.1
Re: [PATCH v3 3/3] gpio: xilinx: Utilize generic bitmap_get_value and _set_value
On 3/6/21 3:06 PM, Syed Nayyar Waris wrote:
> This patch reimplements the xgpio_set_multiple() function in
> drivers/gpio/gpio-xilinx.c to use the new generic functions:
> bitmap_get_value() and bitmap_set_value(). The code is now simpler
> to read and understand. Moreover, instead of looping for each bit
> in xgpio_set_multiple() function, now we can check each channel at
> a time and save cycles.
>
> Cc: Bartosz Golaszewski
> Cc: Michal Simek
> Signed-off-by: Syed Nayyar Waris
> Acked-by: William Breathitt Gray
> ---
> drivers/gpio/gpio-xilinx.c | 63 +++---
> 1 file changed, 32 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
> index be539381fd82..8445e69cf37b 100644
> --- a/drivers/gpio/gpio-xilinx.c
> +++ b/drivers/gpio/gpio-xilinx.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include "gpiolib.h"
>
> /* Register Offset Definitions */
> #define XGPIO_DATA_OFFSET (0x0)/* Data register */
> @@ -141,37 +142,37 @@ static void xgpio_set_multiple(struct gpio_chip *gc,
> unsigned long *mask,
> {
> unsigned long flags;
> struct xgpio_instance *chip = gpiochip_get_data(gc);
> - int index = xgpio_index(chip, 0);
> - int offset, i;
> -
> - spin_lock_irqsave(>gpio_lock[index], flags);
> -
> - /* Write to GPIO signals */
> - for (i = 0; i < gc->ngpio; i++) {
> - if (*mask == 0)
> - break;
> - /* Once finished with an index write it out to the register */
> - if (index != xgpio_index(chip, i)) {
> - xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
> -index * XGPIO_CHANNEL_OFFSET,
> -chip->gpio_state[index]);
> - spin_unlock_irqrestore(>gpio_lock[index], flags);
> - index = xgpio_index(chip, i);
> - spin_lock_irqsave(>gpio_lock[index], flags);
> - }
> - if (__test_and_clear_bit(i, mask)) {
> - offset = xgpio_offset(chip, i);
> - if (test_bit(i, bits))
> - chip->gpio_state[index] |= BIT(offset);
> - else
> - chip->gpio_state[index] &= ~BIT(offset);
> - }
> - }
> -
> - xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
> -index * XGPIO_CHANNEL_OFFSET, chip->gpio_state[index]);
> -
> - spin_unlock_irqrestore(>gpio_lock[index], flags);
> + u32 *const state = chip->gpio_state;
> + unsigned int *const width = chip->gpio_width;
> +
> + DECLARE_BITMAP(old, 64);
> + DECLARE_BITMAP(new, 64);
> + DECLARE_BITMAP(changed, 64);
> +
> + spin_lock_irqsave(>gpio_lock[0], flags);
> + spin_lock(>gpio_lock[1]);
> +
> + bitmap_set_value(old, 64, state[0], width[0], 0);
> + bitmap_set_value(old, 64, state[1], width[1], width[0]);
> + bitmap_replace(new, old, bits, mask, gc->ngpio);
> +
> + bitmap_set_value(old, 64, state[0], 32, 0);
> + bitmap_set_value(old, 64, state[1], 32, 32);
> + state[0] = bitmap_get_value(new, 0, width[0]);
> + state[1] = bitmap_get_value(new, width[0], width[1]);
> + bitmap_set_value(new, 64, state[0], 32, 0);
> + bitmap_set_value(new, 64, state[1], 32, 32);
> + bitmap_xor(changed, old, new, 64);
> +
> + if (((u32 *)changed)[0])
> + xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET,
> + state[0]);
> + if (((u32 *)changed)[1])
> + xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
> + XGPIO_CHANNEL_OFFSET, state[1]);
> +
> + spin_unlock(>gpio_lock[1]);
> + spin_unlock_irqrestore(>gpio_lock[0], flags);
> }
>
> /**
>
Srinivas N: Can you please test this code?
Thanks,
Michal
[PATCH] arm64: dts: zynqmp: Add compatible strings for si5328
From: Quanyang Wang
The function of_i2c_get_board_info will call of_modalias_node to check
if a device_node contains "compatible" string. So let's assign the
proper string "silabs,si5328" to clock-generator@69's compatible
property to eliminate the error info as below:
i2c i2c-10: of_i2c: modalias failure on
/axi/i2c@ff03/i2c-mux@74/i2c@4/clock-generator@69
i2c i2c-10: Failed to create I2C device for
/axi/i2c@ff03/i2c-mux@74/i2c@4/clock-generator@69
Fixes: 82a7ebf00224 ("arm64: dts: zynqmp: Add DT description for si5328 for
zcu102/zcu106")
Signed-off-by: Quanyang Wang
---
arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts | 1 +
arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
index 12e8bd48dc8c..a73841ad24ce 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
@@ -590,6 +590,7 @@ si5328: clock-generator@69 {/* SI5328 - u20 */
#address-cells = <1>;
#size-cells = <0>;
#clock-cells = <1>;
+ compatible = "silabs,si5328";
clocks = <>;
clock-names = "xtal";
clock-output-names = "si5328";
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
index 18771e868399..24ce64364d63 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
@@ -591,6 +591,7 @@ si5328: clock-generator@69 {/* SI5328 - u20 */
#address-cells = <1>;
#size-cells = <0>;
#clock-cells = <1>;
+ compatible = "silabs,si5328";
clocks = <>;
clock-names = "xtal";
clock-output-names = "si5328";
--
2.25.1
Re: [PATCH] x86/perf: Fix guest_get_msrs static call if there is no PMU
On Mon, Mar 8, 2021 at 3:26 AM Xu, Like wrote:
>
> On 2021/3/6 6:33, Sean Christopherson wrote:
> > Handle a NULL x86_pmu.guest_get_msrs at invocation instead of patching
> > in perf_guest_get_msrs_nop() during setup. If there is no PMU, setup
>
> "If there is no PMU" ...
>
> How to set up this kind of environment,
> and what changes are needed in .config or boot parameters ?
Hi Xu,
This can be reproduced in qemu with "-cpu max,-pmu" flag using this reproducer:
https://groups.google.com/g/syzkaller-bugs/c/D8eHw3LIOd0/m/L2G0lVkVBAAJ
> > bails before updating the static calls, leaving x86_pmu.guest_get_msrs
> > NULL and thus a complete nop.
>
> > Ultimately, this causes VMX abort on
> > VM-Exit due to KVM putting random garbage from the stack into the MSR
> > load list.
> >
> > Fixes: abd562df94d1 ("x86/perf: Use static_call for x86_pmu.guest_get_msrs")
> > Cc: Like Xu
> > Cc: Paolo Bonzini
> > Cc: Jim Mattson
> > Cc: k...@vger.kernel.org
> > Reported-by: Dmitry Vyukov
> > Signed-off-by: Sean Christopherson
> > ---
> > arch/x86/events/core.c | 16 +---
> > 1 file changed, 5 insertions(+), 11 deletions(-)
> >
> > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> > index 6ddeed3cd2ac..ff874461f14c 100644
> > --- a/arch/x86/events/core.c
> > +++ b/arch/x86/events/core.c
> > @@ -671,7 +671,11 @@ void x86_pmu_disable_all(void)
> >
> > struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr)
> > {
> > - return static_call(x86_pmu_guest_get_msrs)(nr);
> > + if (x86_pmu.guest_get_msrs)
> > + return static_call(x86_pmu_guest_get_msrs)(nr);
>
> How about using "static_call_cond" per commit "452cddbff7" ?
>
> > +
> > + *nr = 0;
> > + return NULL;
> > }
> > EXPORT_SYMBOL_GPL(perf_guest_get_msrs);
> >
> > @@ -1944,13 +1948,6 @@ static void _x86_pmu_read(struct perf_event *event)
> > x86_perf_event_update(event);
> > }
> >
> > -static inline struct perf_guest_switch_msr *
> > -perf_guest_get_msrs_nop(int *nr)
> > -{
> > - *nr = 0;
> > - return NULL;
> > -}
> > -
> > static int __init init_hw_perf_events(void)
> > {
> > struct x86_pmu_quirk *quirk;
> > @@ -2024,9 +2021,6 @@ static int __init init_hw_perf_events(void)
> > if (!x86_pmu.read)
> > x86_pmu.read = _x86_pmu_read;
> >
> > - if (!x86_pmu.guest_get_msrs)
> > - x86_pmu.guest_get_msrs = perf_guest_get_msrs_nop;
> > -
> > x86_pmu_static_call_update();
> >
> > /*
>
drivers/usb/gadget/function/f_fs.c:3829:8-15: WARNING opportunity for memdup_user
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 144c79ef33536b4ecb4951e07dbc1f2b7fa99d32 commit: 8704fd73bf5658bf4b827643f7f526481082d83f USB: gadget: f_fs: remove likely/unlikely date: 3 months ago config: x86_64-randconfig-c002-20210307 (attached as .config) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot "coccinelle warnings: (new ones prefixed by >>)" >> drivers/usb/gadget/function/f_fs.c:3829:8-15: WARNING opportunity for >> memdup_user Please review and possibly fold the followup patch. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH] USB: gadget: f_fs: fix memdup_user.cocci warnings
From: kernel test robot
drivers/usb/gadget/function/f_fs.c:3829:8-15: WARNING opportunity for
memdup_user
Use memdup_user rather than duplicating its implementation
This is a little bit restricted to reduce false positives
Generated by: scripts/coccinelle/api/memdup_user.cocci
Fixes: 8704fd73bf56 ("USB: gadget: f_fs: remove likely/unlikely")
Reported-by: kernel test robot
Signed-off-by: kernel test robot
---
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 144c79ef33536b4ecb4951e07dbc1f2b7fa99d32
commit: 8704fd73bf5658bf4b827643f7f526481082d83f USB: gadget: f_fs: remove
likely/unlikely
f_fs.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -3826,14 +3826,9 @@ static char *ffs_prepare_buffer(const ch
if (!len)
return NULL;
- data = kmalloc(len, GFP_KERNEL);
- if (!data)
- return ERR_PTR(-ENOMEM);
-
- if (copy_from_user(data, buf, len)) {
- kfree(data);
- return ERR_PTR(-EFAULT);
- }
+ data = memdup_user(buf, len);
+ if (IS_ERR(data))
+ return ERR_PTR(PTR_ERR(data));
pr_vdebug("Buffer from user space:\n");
ffs_dump_mem("", data, len);
[PATCH] phy: hisilicon: add missing call to of_node_put()
In one of the error paths of the for_each_child_of_node() loop,
add missing call to of_node_put().
Fix the following coccicheck warning:
./drivers/phy/hisilicon/phy-hisi-inno-usb2.c:138:1-23: WARNING: Function
"for_each_child_of_node" should have of_node_put() before break around
line 158.
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/phy/hisilicon/phy-hisi-inno-usb2.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
b/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
index 34a6a9a..c58115e 100644
--- a/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
+++ b/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
@@ -146,8 +146,10 @@ static int hisi_inno_phy_probe(struct platform_device
*pdev)
priv->ports[i].priv = priv;
phy = devm_phy_create(dev, child, _inno_phy_ops);
- if (IS_ERR(phy))
+ if (IS_ERR(phy)) {
+ of_node_put(child);
return PTR_ERR(phy);
+ }
phy_set_bus_width(phy, 8);
phy_set_drvdata(phy, >ports[i]);
--
1.8.3.1
Re: [block] 52f019d43c: ndctl.test-libndctl.fail
On Sat, Mar 06, 2021 at 08:33:04PM +, Williams, Dan J wrote: > Yes, it looks like my unit test checks for exactly the behavior you > changed. It was convenient to test that the device could be switched > back to rw via BLKROSET, but I don't require that. The new behaviour of > letting the disk->ro take precedence makes more sense to me, so I'll > update the test for the new behaviour. > > I.e. I don't think regressing a unit test counts as a userspace > regression. Ok, thanks for the confirmation.
[PATCH] arm64: dts: mt8173: fix property typo of 'phys' in dsi node
Use 'phys' instead of 'phy'.
Fixes: 81ad4dbaf7af ("arm64: dts: mt8173: Add display subsystem related nodes")
Cc: stable
Signed-off-by: Chunfeng Yun
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 75040a820f0d..003a5653c505 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -1236,7 +1236,7 @@
< CLK_MM_DSI1_DIGITAL>,
<_tx1>;
clock-names = "engine", "digital", "hs";
- phy = <_tx1>;
+ phys = <_tx1>;
phy-names = "dphy";
status = "disabled";
};
--
2.18.0
[PATCH v4] coccinelle: misc: add minmax script
Check for opencoded min(), max() implementations.
Signed-off-by: Denis Efremov
---
Changes in v2:
- <... ...> instead of ... when any
- org mode reports fixed
- patch rule to drop excessive ()
Changes in v3:
- "depends on patch && (pmax || pmaxif || pmin || pminif)" fixed
Changes in v4:
- refarmatting rule removed
- () brackets added to the patch rules to omit excessive ones
- org/report prints changed to cycle (for p0 in p: ...)
scripts/coccinelle/misc/minmax.cocci | 206 +++
1 file changed, 206 insertions(+)
create mode 100644 scripts/coccinelle/misc/minmax.cocci
diff --git a/scripts/coccinelle/misc/minmax.cocci
b/scripts/coccinelle/misc/minmax.cocci
new file mode 100644
index ..63eeba1702ec
--- /dev/null
+++ b/scripts/coccinelle/misc/minmax.cocci
@@ -0,0 +1,206 @@
+// SPDX-License-Identifier: GPL-2.0-only
+///
+/// Check for opencoded min(), max() implementations.
+/// Generated patches sometimes require adding a cast to fix compile warning.
+/// Warnings/patches scope intentionally limited to a function body.
+///
+// Confidence: Medium
+// Copyright: (C) 2021 Denis Efremov ISPRAS
+// Options: --no-includes --include-headers
+//
+// Keywords: min, max
+//
+
+
+virtual report
+virtual org
+virtual context
+virtual patch
+
+@rmax depends on !patch@
+identifier func;
+expression x, y;
+binary operator cmp = {>, >=};
+position p;
+@@
+
+func(...)
+{
+ <...
+* ((x) cmp@p (y) ? (x) : (y))
+ ...>
+}
+
+@rmaxif depends on !patch@
+identifier func;
+expression x, y;
+expression max_val;
+binary operator cmp = {>, >=};
+position p;
+@@
+
+func(...)
+{
+ <...
+* if ((x) cmp@p (y)) {
+* max_val = (x);
+* } else {
+* max_val = (y);
+* }
+ ...>
+}
+
+@rmin depends on !patch@
+identifier func;
+expression x, y;
+binary operator cmp = {<, <=};
+position p;
+@@
+
+func(...)
+{
+ <...
+* ((x) cmp@p (y) ? (x) : (y))
+ ...>
+}
+
+@rminif depends on !patch@
+identifier func;
+expression x, y;
+expression min_val;
+binary operator cmp = {<, <=};
+position p;
+@@
+
+func(...)
+{
+ <...
+* if ((x) cmp@p (y)) {
+* min_val = (x);
+* } else {
+* min_val = (y);
+* }
+ ...>
+}
+
+@pmax depends on patch@
+identifier func;
+expression x, y;
+binary operator cmp = {>=, >};
+@@
+
+func(...)
+{
+ <...
+- ((x) cmp (y) ? (x) : (y))
++ max(x, y)
+ ...>
+}
+
+@pmaxif depends on patch@
+identifier func;
+expression x, y;
+expression max_val;
+binary operator cmp = {>=, >};
+@@
+
+func(...)
+{
+ <...
+- if ((x) cmp (y)) {
+- max_val = (x);
+- } else {
+- max_val = (y);
+- }
++ max_val = max(x, y);
+ ...>
+}
+
+@pmin depends on patch@
+identifier func;
+expression x, y;
+binary operator cmp = {<=, <};
+@@
+
+func(...)
+{
+ <...
+- ((x) cmp (y) ? (x) : (y))
++ min(x, y)
+ ...>
+}
+
+@pminif depends on patch@
+identifier func;
+expression x, y;
+expression min_val;
+binary operator cmp = {<=, <};
+@@
+
+func(...)
+{
+ <...
+- if ((x) cmp (y)) {
+- min_val = (x);
+- } else {
+- min_val = (y);
+- }
++ min_val = min(x, y);
+ ...>
+}
+
+@script:python depends on report@
+p << rmax.p;
+@@
+
+for p0 in p:
+ coccilib.report.print_report(p0, "WARNING opportunity for max()")
+
+@script:python depends on org@
+p << rmax.p;
+@@
+
+for p0 in p:
+ coccilib.org.print_todo(p0, "WARNING opportunity for max()")
+
+@script:python depends on report@
+p << rmaxif.p;
+@@
+
+for p0 in p:
+ coccilib.report.print_report(p0, "WARNING opportunity for max()")
+
+@script:python depends on org@
+p << rmaxif.p;
+@@
+
+for p0 in p:
+ coccilib.org.print_todo(p0, "WARNING opportunity for max()")
+
+@script:python depends on report@
+p << rmin.p;
+@@
+
+for p0 in p:
+ coccilib.report.print_report(p0, "WARNING opportunity for min()")
+
+@script:python depends on org@
+p << rmin.p;
+@@
+
+for p0 in p:
+ coccilib.org.print_todo(p0, "WARNING opportunity for min()")
+
+@script:python depends on report@
+p << rminif.p;
+@@
+
+for p0 in p:
+ coccilib.report.print_report(p0, "WARNING opportunity for min()")
+
+@script:python depends on org@
+p << rminif.p;
+@@
+
+for p0 in p:
+ coccilib.org.print_todo(p0, "WARNING opportunity for min()")
--
2.26.2
RE: [EXT] Re: vfio-pci: protect remap_pfn_range() from simultaneous calls
> -Original Message-
> From: Ankur Arora
> Sent: Monday, March 8, 2021 12:29 PM
> To: Bharat Bhushan
> Cc: alex.william...@redhat.com; linux-kernel@vger.kernel.org; Sunil Kovvuri
> Goutham ; termi...@gmail.com
> Subject: Re: [EXT] Re: vfio-pci: protect remap_pfn_range() from simultaneous
> calls
>
> On 2021-03-02 4:47 a.m., Bharat Bhushan wrote:
> > Hi Ankur,
> >
> >> -Original Message-
> >> From: Ankur Arora
> >> Sent: Friday, February 26, 2021 6:24 AM
> >> To: Bharat Bhushan
> >> Cc: alex.william...@redhat.com; ankur.a.ar...@oracle.com; linux-
> >> ker...@vger.kernel.org; Sunil Kovvuri Goutham ;
> >> termi...@gmail.com
> >> Subject: [EXT] Re: vfio-pci: protect remap_pfn_range() from
> >> simultaneous calls
> >>
> >> External Email
> >>
> >> -
> >> -
> >> Hi Bharat,
> >>
> >> Can you test the patch below to see if it works for you?
> >
> > Sorry for late reply, I actually missed this email.
> >
> > Reproducibility of the issue was low in my test scenario, one out of ~15
> > runs. I
> run it multiple times, overnight and observed no issues.
>
> Awesome. Would you mind giving me your Tested-by for the patch?
Sure, please point if this is already sent for review.
>
> >> Also could you add some more detail to your earlier description of
> >> the bug?
> >
> > Our test case is running ODP multi-threaded application, where parent
> > process
> maps (yes it uses MAP_DMA) the region and then child processes access same.
> As a workaround we tried accessing the region once by parent process before
> creating other accessor threads and it worked as expected.
>
> Thanks for the detail. So if the child processes start early -- they might
> fault while
> the VFIO_IOMMU_MAP_DMA was going on. And, since they only acquire
> mmap_lock in RO mode, both paths would end up calling io_remap_pfn_range()
> via the fault handler.
Yes, that's correct.
Thanks
-Bharat
>
> Thanks
> Ankur
>
> >
> > Thanks
> > -Bharat
> >
> >> In particular, AFAICS you are using ODP (-DPDK?) with multiple
> >> threads touching this region. From your stack, it looks like the
> >> fault was user-space generated, and I'm guessing you were not using
> >> the VFIO_IOMMU_MAP_DMA.
> >>
> >> Ankur
> >>
> >> -- >8 --
> >>
> >> Subject: [PATCH] vfio-pci: protect io_remap_pfn_range() from
> >> simultaneous calls
> >>
> >> vfio_pci_mmap_fault() maps the complete VMA on fault. With concurrent
> >> faults, this would result in multiple calls to io_remap_pfn_range(),
> >> where it would hit a BUG_ON(!pte_none(*pte)) in remap_pte_range().
> >> (It would also link the same VMA multiple times in vdev->vma_list but
> >> given the BUG_ON that is less serious.)
> >>
> >> Normally, however, this won't happen -- at least with
> >> vfio_iommu_type1 -- the VFIO_IOMMU_MAP_DMA path is protected by
> iommu->lock.
> >>
> >> If, however, we are using some kind of parallelization mechanism like
> >> this one with ktask under discussion [1], we would hit this.
> >> Even if we were doing this serially, given that vfio-pci remaps a
> >> larger extent than strictly necessary it should internally enforce
> >> coherence of its data structures.
> >>
> >> Handle this by using the VMA's presence in the vdev->vma_list as
> >> indicative of a fully mapped VMA and returning success early to all
> >> but the first VMA fault. Note that this is clearly optimstic given
> >> that the mapping is ongoing, and might mean that the caller sees more
> >> faults until the remap is done.
> >>
> >> [1]
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_
> >> linux-
> >> 2Dmm_20181105145141.6f9937f6-
> >>
> 40w520.home_=DwIDAg=nKjWec2b6R0mOyPaz7xtfQ=PAAlWswPe7d8gHl
> >>
> GbCLmy2YezyK7O3Hv_t2heGnouBw=3ZDXqnn9xNUCjgXwN9mHIKT7oyXu55P
> >> U7yV2j0b-5hw=hiICkNtrcH4AbAWRrbkvMUylp7Bv0YHFCjxNGC6CGOk=
> >>
> >> Signed-off-by: Ankur Arora
> >> ---
> >> drivers/vfio/pci/vfio_pci.c | 25 -
> >> 1 file changed, 24 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/vfio/pci/vfio_pci.c
> >> b/drivers/vfio/pci/vfio_pci.c index 65e7e6b44578..b9f509863db1 100644
> >> --- a/drivers/vfio/pci/vfio_pci.c
> >> +++ b/drivers/vfio/pci/vfio_pci.c
> >> @@ -1573,6 +1573,11 @@ static int __vfio_pci_add_vma(struct
> >> vfio_pci_device *vdev,
> >> {
> >>struct vfio_pci_mmap_vma *mmap_vma;
> >>
> >> + list_for_each_entry(mmap_vma, >vma_list, vma_next) {
> >> + if (mmap_vma->vma == vma)
> >> + return 1;
> >> + }
> >> +
> >>mmap_vma = kmalloc(sizeof(*mmap_vma), GFP_KERNEL);
> >>if (!mmap_vma)
> >>return -ENOMEM;
> >> @@ -1613,6 +1618,7 @@ static vm_fault_t vfio_pci_mmap_fault(struct
> >> vm_fault
> >> *vmf)
> >>struct vm_area_struct *vma = vmf->vma;
> >>struct vfio_pci_device *vdev = vma->vm_private_data;
> >>vm_fault_t ret = VM_FAULT_NOPAGE;
> >> + int vma_present;
> >>
> >>mutex_lock(>vma_lock);
> >>
Re: [RFC 1/1] s390/pci: expose a PCI device's UID as its index
On 3/7/21 9:46 PM, Krzysztof Wilczyński wrote:
> Hi Niklas,
>
> [...]
>> +static ssize_t index_show(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> +struct zpci_dev *zdev = to_zpci(to_pci_dev(dev));
>> +u32 index = ~0;
>> +
>> +if (zpci_unique_uid)
>> +index = zdev->uid;
>> +
>> +return sprintf(buf, "%u\n", index);
> [...]
>
> Would it be possible to use the new sysfs_emit() rather than sprintf()
> even though the zpci_attr macro and still use mio_enabled_show() still
> would use sprintf(). What do you think?
>
> See https://www.kernel.org/doc/html/latest/filesystems/sysfs.html for
> the changes in the internal API.
>
> Krzysztof
>
Of course that makes sense and thanks for pointing me to this API!
@Viktor, may I carry your R-b over?
I'll also update the other attributes in a clean up patch.
Thanks,
Niklas
Re: [EXT] Re: vfio-pci: protect remap_pfn_range() from simultaneous calls
On 2021-03-02 4:47 a.m., Bharat Bhushan wrote:
Hi Ankur,
-Original Message-
From: Ankur Arora
Sent: Friday, February 26, 2021 6:24 AM
To: Bharat Bhushan
Cc: alex.william...@redhat.com; ankur.a.ar...@oracle.com; linux-
ker...@vger.kernel.org; Sunil Kovvuri Goutham ;
termi...@gmail.com
Subject: [EXT] Re: vfio-pci: protect remap_pfn_range() from simultaneous calls
External Email
--
Hi Bharat,
Can you test the patch below to see if it works for you?
Sorry for late reply, I actually missed this email.
Reproducibility of the issue was low in my test scenario, one out of ~15 runs.
I run it multiple times, overnight and observed no issues.
Awesome. Would you mind giving me your Tested-by for the
patch?
Also could you add some more detail to your earlier description of
the bug?
Our test case is running ODP multi-threaded application, where parent process
maps (yes it uses MAP_DMA) the region and then child processes access same. As
a workaround we tried accessing the region once by parent process before
creating other accessor threads and it worked as expected.
Thanks for the detail. So if the child processes start early -- they
might fault while the VFIO_IOMMU_MAP_DMA was going on. And, since
they only acquire mmap_lock in RO mode, both paths would end up
calling io_remap_pfn_range() via the fault handler.
Thanks
Ankur
Thanks
-Bharat
In particular, AFAICS you are using ODP (-DPDK?) with multiple
threads touching this region. From your stack, it looks like the
fault was user-space generated, and I'm guessing you were not
using the VFIO_IOMMU_MAP_DMA.
Ankur
-- >8 --
Subject: [PATCH] vfio-pci: protect io_remap_pfn_range() from simultaneous calls
vfio_pci_mmap_fault() maps the complete VMA on fault. With concurrent
faults, this would result in multiple calls to io_remap_pfn_range(),
where it would hit a BUG_ON(!pte_none(*pte)) in remap_pte_range().
(It would also link the same VMA multiple times in vdev->vma_list
but given the BUG_ON that is less serious.)
Normally, however, this won't happen -- at least with vfio_iommu_type1 --
the VFIO_IOMMU_MAP_DMA path is protected by iommu->lock.
If, however, we are using some kind of parallelization mechanism like
this one with ktask under discussion [1], we would hit this.
Even if we were doing this serially, given that vfio-pci remaps a larger
extent than strictly necessary it should internally enforce coherence of
its data structures.
Handle this by using the VMA's presence in the vdev->vma_list as
indicative of a fully mapped VMA and returning success early to
all but the first VMA fault. Note that this is clearly optimstic given
that the mapping is ongoing, and might mean that the caller sees
more faults until the remap is done.
[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_linux-
2Dmm_20181105145141.6f9937f6-
40w520.home_=DwIDAg=nKjWec2b6R0mOyPaz7xtfQ=PAAlWswPe7d8gHl
GbCLmy2YezyK7O3Hv_t2heGnouBw=3ZDXqnn9xNUCjgXwN9mHIKT7oyXu55P
U7yV2j0b-5hw=hiICkNtrcH4AbAWRrbkvMUylp7Bv0YHFCjxNGC6CGOk=
Signed-off-by: Ankur Arora
---
drivers/vfio/pci/vfio_pci.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 65e7e6b44578..b9f509863db1 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -1573,6 +1573,11 @@ static int __vfio_pci_add_vma(struct vfio_pci_device
*vdev,
{
struct vfio_pci_mmap_vma *mmap_vma;
+ list_for_each_entry(mmap_vma, >vma_list, vma_next) {
+ if (mmap_vma->vma == vma)
+ return 1;
+ }
+
mmap_vma = kmalloc(sizeof(*mmap_vma), GFP_KERNEL);
if (!mmap_vma)
return -ENOMEM;
@@ -1613,6 +1618,7 @@ static vm_fault_t vfio_pci_mmap_fault(struct vm_fault
*vmf)
struct vm_area_struct *vma = vmf->vma;
struct vfio_pci_device *vdev = vma->vm_private_data;
vm_fault_t ret = VM_FAULT_NOPAGE;
+ int vma_present;
mutex_lock(>vma_lock);
down_read(>memory_lock);
@@ -1623,7 +1629,21 @@ static vm_fault_t vfio_pci_mmap_fault(struct
vm_fault *vmf)
goto up_out;
}
- if (__vfio_pci_add_vma(vdev, vma)) {
+ /*
+* __vfio_pci_add_vma() either adds the vma to the vdev->vma_list
+* (vma_present == 0), or indicates that the vma is already present
+* on the list (vma_present == 1).
+*
+* Overload the meaning of this flag to also imply that the vma is
+* fully mapped. This allows us to serialize the mapping -- ensuring
+* that simultaneous faults will not both try to call
+* io_remap_pfn_range().
+*
+* However, this might mean that callers to which we returned success
+* optimistically will see more faults until the remap is complete.
+*/
+ vma_present =
Re: [PATCH v9 2/9] x509: Detect sm2 keys by their parameters OID
Hi, On 3/5/21 11:04 PM, Stefan Berger wrote: On 3/5/21 2:37 AM, Tianjia Zhang wrote: Hi, On 3/4/21 7:46 AM, Stefan Berger wrote: Tianjia, can you say whether SM2 support works for you before and after applying this patch? I cannot verify it with an sm2 key I have created using a sequence of commands like this: > modprobe sm2_generic > id=$(keyctl newring test @u) > keyctl padd asymmetric "" $id < sm2.der add_key: Key was rejected by service > keyctl padd asymmetric "" $id < eckeys/cert-prime192v1-0.der 88506426 The sm2 key is reject but the pime192v1 key works just fine. SM2 support neither worked for me before nor after this patch here. The difference is that before it returned 'add_key: Package not installed'. This is my sm2 cert: > base64 < sm2.der MIIBbzCCARWgAwIBAgIUfqwndeAy7reymWLwvCHOgYPU2YUwCgYIKoZIzj0EAwIwDTELMAkGA1UE AwwCbWUwHhcNMjEwMTI0MTgwNjQ3WhcNMjIwMTI0MTgwNjQ3WjANMQswCQYDVQQDDAJtZTBZMBMG ByqGSM49AgEGCCqBHM9VAYItA0IABEtiMaczdk46MEugmOsY/u+puf5qoi7JdLd/w3VpdixvDd26 vrxLKL7lCTVn5w3a07G7QB1dgdMDpzIRgWrVXC6jUzBRMB0GA1UdDgQWBBSxOVnE7ihvTb6Nczb4 /mow+HIc9TAfBgNVHSMEGDAWgBSxOVnE7ihvTb6Nczb4/mow+HIc9TAPBgNVHRMBAf8EBTADAQH/ MAoGCCqGSM49BAMCA0gAMEUCIE1kiji2ABUy663NANe0iCPjCeeqg02Yk4b3K+Ci/Qh4AiEA/cFB eJEVklyveRMvuTP7BN7FG4U8iRdtedjiX+YrNio= Regards, Stefan Yes, it works fine here. Your test method may be wrong. First of all, the certificate looks wrong, I don’t know if it is not sent completely. Secondly, the SM2 algorithm must be compiled with builtin. There will be a problem when it is compiled into a module. This is a restriction for SM2 signature with Za. you may refer to this discussion: https://lkml.org/lkml/2021/1/12/1736 In addition, give you a self-signed root certificate for my test: -BEGIN CERTIFICATE- MIICLjCCAdWgAwIBAgIUEoozP6LzMYWh4gCpcWlzsUyfgsIwCgYIKoEcz1UBg3Uw bTELMAkGA1UEBhMCQ04xCzAJBgNVBAgMAkdTMQswCQYDVQQHDAJHdDENMAsGA1UE CgwEYmFiYTELMAkGA1UECwwCT1MxCzAJBgNVBAMMAmNhMRswGQYJKoZIhvcNAQkB FgxjYUB3b3JsZC5jb20wHhcNMjAwNDE1MTE1NDA3WhcNMzAwNDEzMTE1NDA3WjBt MQswCQYDVQQGEwJDTjELMAkGA1UECAwCR1MxCzAJBgNVBAcMAkd0MQ0wCwYDVQQK DARiYWJhMQswCQYDVQQLDAJPUzELMAkGA1UEAwwCY2ExGzAZBgkqhkiG9w0BCQEW DGNhQHdvcmxkLmNvbTBZMBMGByqGSM49AgEGCCqBHM9VAYItA0IABMTGRiHezKm5 MiKHlyfa5Bv5jLxge/WRRG0nLNsZx1yf0XQTQBR/tFFjPGePEr7+Fa1CPgYpXExx i44coYMmQT6jUzBRMB0GA1UdDgQWBBSjd9GWIe98Ll9J0dquxgCktp9DrTAfBgNV HSMEGDAWgBSjd9GWIe98Ll9J0dquxgCktp9DrTAPBgNVHRMBAf8EBTADAQH/MAoG CCqBHM9VAYN1A0cAMEQCIAvLWIfGFq85u/vVMLc5H1D/DnrNS0VhSkQA4daRO4tc AiABbeWENcQZDZLWTuqG9P2KDPOoNqV/QV/+0XjMAVblhg== -END CERTIFICATE- If you can, please add: Tested-by: Tianjia Zhang good luck! It works with your certificate! When I create the sm2 with OpenSSL on Ubuntu, which seems to have sm2 support, or so one may think, I get this type of signature: I cannot create it with sm3, if that's how this is supposed to be signed: > # openssl req -x509 -sm3 -newkey ec -pkeyopt ec_paramgen_curve:sm2 -keyout sm2key.pem -days 365 -subj '/CN=test' -nodes -outform der -out sm2.der parameter error "ec_paramgen_curve:sm2" 140735899258064:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:crypto/ec/ec_curve.c:418: 140735899258064:error:100C508D:elliptic curve routines:pkey_ec_ctrl:invalid curve:crypto/ec/ec_pmeth.c:231: Using sha256 instead, which is the mistake: > openssl req -x509 -sha256 -newkey ec -pkeyopt ec_paramgen_curve:sm2 -keyout sm2key.pem -days 365 -subj '/CN=test' -nodes -outform der -out sm2-2nd.der > openssl x509 -inform der -in sm2-2nd.der -noout -text [...] Signature Algorithm: ecdsa-with-SHA256 30:45:02:20:05:72:15:b0:e8:f5:5a:27:d2:fb:f9:de:de:35: 05:b2:76:8a:6f:84:c1:54:db:c2:38:8c:d2:64:8b:67:23:01: 02:21:00:97:77:9e:42:fa:41:3d:d4:81:5e:5b:ad:9e:56:ad: 46:fc:5e:94:92:a6:07:2d:af:62:d2:2d:39:7b:71:f1:4a Yours has this type of signature: Signature Algorithm: 1.2.156.10197.1.501 30:44:02:20:0b:cb:58:87:c6:16:af:39:bb:fb:d5:30:b7:39: 1f:50:ff:0e:7a:cd:4b:45:61:4a:44:00:e1:d6:91:3b:8b:5c: 02:20:01:6d:e5:84:35:c4:19:0d:92:d6:4e:ea:86:f4:fd:8a: 0c:f3:a8:36:a5:7f:41:5f:fe:d1:78:cc:01:56:e5:86 Thanks anyway! Stefan I guess it may be that your openssl version is too low. At present, only openssl 3.0.0 (still in the alpha stage and not yet officially released) can support the certificate of the SM2-with-SM3 algorithm combination. This is the command I used in openssl-3.0.0-alpha6: openssl ecparam -genkey -name SM2 -text -out ca.key openssl req -new \ -x509 -days 3650 \ -sm3 -sigopt "distid:1234567812345678" \ -key ca.key \ -out ca.crt \ -subj "/C=CN/ST=GS/L=Gt/O=baba/OU=OS/CN=ca/emailAddress=c...@world.com"
Re: linux-kernel janitorial RFP: Mark static arrays as const
On Sun, 7 Mar 2021, Joe Perches wrote:
> On Sun, 2021-03-07 at 20:14 +0100, Julia Lawall wrote:
> >
> > On Wed, 3 Mar 2021, Joe Perches wrote:
> >
> > > On Wed, 2021-03-03 at 10:41 +0100, Rasmus Villemoes wrote:
> > > > On 02/03/2021 18.42, Joe Perches wrote:
> > > > > Here is a possible opportunity to reduce data usage in the kernel.
> > > > >
> > > > > $ git grep -P -n
> > > > > '^static\s+(?!const|struct)(?:\w+\s+){1,3}\w+\s*\[\s*\]' drivers/ | \
> > > > > grep -v __initdata | \
> > > > > wc -l
> > > > > 3250
> > > > >
> > > > > Meaning there are ~3000 declarations of arrays with what appears to be
> > > > > file static const content that are not marked const.
> > > > >
> > > > > So there are many static arrays that could be marked const to move the
> > > > > compiled object code from data to text minimizing the total amount of
> > > > > exposed r/w data.
> > > >
> > > > You can add const if you like, but it will rarely change the generated
> > > > code. gcc is already smart enough to take a static array whose contents
> > > > are provably never modified within the TU and put it in .rodata:
> > >
> > > At least some or perhaps even most of the time, true, but the gcc compiler
> > > from v5 through at least v10 seems inconsistent about when it does the
> > > appropriate conversion.
> > >
> > > See the example I posted:
> > > https://lore.kernel.org/lkml/6b8b250a06a98ce42120a14824531a8641f5e8aa.ca...@perches.com/
> > >
> > > It was a randomly chosen source file conversion btw, I had no prior
> > > knowledge of whether the text/data use would change.
> > >
> > > I'm unsure about clang consistently moving static but provably const
> > > arrays
> > > from data to text. I rarely use clang. At least for v11 it seems to be
> > > better though. I didn't try 10.1.
> >
> > I tried the relevnt drivers in drivers/input/joystick. I got only one
> > driver that changed with gcc 9.3, which was
> > drivers/input/joystick/analog.c. It actually got larger:
> >
> > original:
> >
> > textdata bss dec hex filename
> > 22607 10560 320 3348782cf drivers/input/joystick/analog.o
> >
> > after adding const:
> >
> > textdata bss dec hex filename
> > 22728 10816 320 338648448 drivers/input/joystick/analog.o
> >
> > This was the only case where bss was not 0, but I don't know if there is a
> > connection.
>
> You really need consider using defconfig so whatever object code
> does not have tracing/debugging support.
>
> For instance, this code with defconfig and analog joystick:
>
> Original:
>
> $ size drivers/input/joystick/analog.o
>text data bss dec hex filename
>8115 261 22486002198 drivers/input/joystick/analog.o
>
> with const:
>
> $ size drivers/input/joystick/analog.o
>text data bss dec hex filename
>8179 201 2248604219c drivers/input/joystick/analog.o
Thanks for the suggestion. It occurred to me that in one case my
transformation was wrong, because the array was multi-level, and a sub
array was being stored in a structure field that was not declared as
const. So the argument that the compiler would figure out to put the
array in .rodata didn't make sense. But I still go the same sizes for
that file. So I'll try the whole thing again.
thanks,
julia
Re: [v8 PATCH 07/13] mm: vmscan: add shrinker_info_protected() helper
On Tue, Feb 16, 2021 at 4:13 PM Yang Shi wrote: > > The shrinker_info is dereferenced in a couple of places via > rcu_dereference_protected > with different calling conventions, for example, using mem_cgroup_nodeinfo > helper > or dereferencing memcg->nodeinfo[nid]->shrinker_info. And the later patch > will add more dereference places. > > So extract the dereference into a helper to make the code more readable. No > functional change. > > Acked-by: Roman Gushchin > Acked-by: Kirill Tkhai > Acked-by: Vlastimil Babka > Signed-off-by: Yang Shi Reviewed-by: Shakeel Butt
Re: [PATCH] sound: soc: codecs: Fix a spello in the file wm8955.c
On 3/6/21 3:51 AM, Bhaskar Chowdhury wrote:
>
> s/sortd/sorted/
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
> ---
> sound/soc/codecs/wm8955.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/codecs/wm8955.c b/sound/soc/codecs/wm8955.c
> index 513df47bd87d..538bb8b0db39 100644
> --- a/sound/soc/codecs/wm8955.c
> +++ b/sound/soc/codecs/wm8955.c
> @@ -151,7 +151,7 @@ static int wm8955_pll_factors(struct device *dev,
> /* The oscilator should run at should be 90-100MHz, and
>* there's a divide by 4 plus an optional divide by 2 in the
>* output path to generate the system clock. The clock table
> - * is sortd so we should always generate a suitable target. */
> + * is sorted so we should always generate a suitable target. */
> target = Fout * 4;
> if (target < 9000) {
> pll->outdiv = 1;
> --
> 2.26.2
>
--
~Randy
Re: [v8 PATCH 06/13] mm: memcontrol: rename shrinker_map to shrinker_info
On Tue, Feb 16, 2021 at 4:13 PM Yang Shi wrote: > > The following patch is going to add nr_deferred into shrinker_map, the change > will > make shrinker_map not only include map anymore, so rename it to > "memcg_shrinker_info". > And this should make the patch adding nr_deferred cleaner and readable and > make > review easier. Also remove the "memcg_" prefix. > > Acked-by: Vlastimil Babka > Acked-by: Kirill Tkhai > Acked-by: Roman Gushchin > Signed-off-by: Yang Shi Reviewed-by: Shakeel Butt
Re: [v8 PATCH 04/13] mm: vmscan: remove memcg_shrinker_map_size
On Tue, Feb 16, 2021 at 4:13 PM Yang Shi wrote: > > Both memcg_shrinker_map_size and shrinker_nr_max is maintained, but actually > the > map size can be calculated via shrinker_nr_max, so it seems unnecessary to > keep both. > Remove memcg_shrinker_map_size since shrinker_nr_max is also used by > iterating the > bit map. > > Acked-by: Kirill Tkhai > Acked-by: Roman Gushchin > Acked-by: Vlastimil Babka > Signed-off-by: Yang Shi Reviewed-by: Shakeel Butt
[PATCH] MIPS: Enable some missed configs in loongson3_defconfig to support bpftrace
bpftrace is a high-level tracing language for Linux enhanced Berkeley Packet Filter (eBPF) available in recent Linux kernels (4.x). bpftrace uses LLVM as a backend to compile scripts to BPF-bytecode and makes use of BCC for interacting with the Linux BPF system, as well as existing Linux tracing capabilities: kernel dynamic tracing (kprobes), user-level dynamic tracing (uprobes), and tracepoints. According to Linux Kernel Requirements in bpftrace/INSTALL.md [1], the kernel needs to be built with the following options: CONFIG_BPF=y CONFIG_BPF_SYSCALL=y CONFIG_BPF_JIT=y CONFIG_HAVE_EBPF_JIT=y CONFIG_BPF_EVENTS=y CONFIG_FTRACE_SYSCALLS=y CONFIG_FUNCTION_TRACER=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_DYNAMIC_FTRACE=y CONFIG_HAVE_KPROBES=y CONFIG_KPROBES=y CONFIG_KPROBE_EVENTS=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_UPROBES=y CONFIG_UPROBE_EVENTS=y CONFIG_DEBUG_FS=y So enable some missed configs in loongson3_defconfig to make sure the above configs are set after make loongson3_defconfig. [1] https://github.com/iovisor/bpftrace/blob/master/INSTALL.md Signed-off-by: Tiezhu Yang --- arch/mips/configs/loongson3_defconfig | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/mips/configs/loongson3_defconfig b/arch/mips/configs/loongson3_defconfig index 0e79f81..1b8f693 100644 --- a/arch/mips/configs/loongson3_defconfig +++ b/arch/mips/configs/loongson3_defconfig @@ -26,6 +26,7 @@ CONFIG_SCHED_AUTOGROUP=y CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y +CONFIG_BPF_SYSCALL=y CONFIG_EMBEDDED=y CONFIG_PERF_EVENTS=y CONFIG_MACH_LOONGSON64=y @@ -40,6 +41,7 @@ CONFIG_MIPS32_N32=y CONFIG_VIRTUALIZATION=y CONFIG_KVM=m CONFIG_KVM_MIPS_VZ=y +CONFIG_KPROBES=y CONFIG_MODULES=y CONFIG_MODULE_FORCE_LOAD=y CONFIG_MODULE_UNLOAD=y @@ -129,6 +131,7 @@ CONFIG_L2TP=m CONFIG_BRIDGE=m CONFIG_VSOCKETS=m CONFIG_VIRTIO_VSOCKETS=m +CONFIG_BPF_JIT=y CONFIG_CFG80211=m CONFIG_CFG80211_WEXT=y CONFIG_MAC80211=m @@ -405,8 +408,10 @@ CONFIG_CRYPTO_DEFLATE=m CONFIG_PRINTK_TIME=y CONFIG_STRIP_ASM_SYMS=y CONFIG_MAGIC_SYSRQ=y +CONFIG_DEBUG_FS=y # CONFIG_SCHED_DEBUG is not set # CONFIG_DEBUG_PREEMPT is not set -# CONFIG_FTRACE is not set +CONFIG_FUNCTION_TRACER=y +CONFIG_FTRACE_SYSCALLS=y CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE="ieee754=relaxed" -- 2.1.0
Re: [PATCH] mm,hwpoison: return -EBUSY when page already poisoned
On Fri, Mar 05, 2021 at 02:11:43PM -0800, Luck, Tony wrote: > This whole page table walking patch is trying to work around the > races caused by multiple calls to memory_failure() for the same > page. > > Maybe better to just avoid the races. The comment right above > memory_failure says: > > * Must run in process context (e.g. a work queue) with interrupts > * enabled and no spinlocks hold. > > So it should be safe to grab and hold a mutex. See patch below. The mutex approach looks simpler and safer, so I'm fine with it. > > -Tony > > commit 8dd0dbe7d595e02647e9c2c76c03341a9f6bd7b9 > Author: Tony Luck > Date: Fri Mar 5 10:40:48 2021 -0800 > > Use a mutex to avoid memory_failure() races > > diff --git a/mm/memory-failure.c b/mm/memory-failure.c > index 24210c9bd843..c1509f4b565e 100644 > --- a/mm/memory-failure.c > +++ b/mm/memory-failure.c > @@ -1381,6 +1381,8 @@ static int memory_failure_dev_pagemap(unsigned long > pfn, int flags, > return rc; > } > > +static DEFINE_MUTEX(mf_mutex); > + > /** > * memory_failure - Handle memory failure of a page. > * @pfn: Page Number of the corrupted page > @@ -1424,12 +1426,18 @@ int memory_failure(unsigned long pfn, int flags) > return -ENXIO; > } > > + mutex_lock(_mutex); Is it better to take mutex before memory_failure_dev_pagemap() block? Or we don't have to protect against race for device memory? Thanks, Naoya Horiguchi
Re: [PATCH v1 1/1] mtd: spi-nor: intel-spi: Move platform data header to x85 subfolder
On Thu, 4 Mar 2021 16:08:20 +0200, Andy Shevchenko wrote: > In order to group x86 related platform data move intel-spi.h to x85 folder. > > While at it, remove duplicate inclusion in C file. s/x85/x86 in subject and commit description and applied to spi-nor/next. Thanks! [1/1] mtd: spi-nor: intel-spi: Move platform data header to x85 subfolder https://git.kernel.org/mtd/c/ae2177cf318d Best regards, -- Tudor Ambarus
[PATCH] docs: gpu: fix typo
Signed-off-by: Jianhui Zhao --- Documentation/gpu/todo.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 40ccac61137e..b7f1acb355f5 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -700,7 +700,7 @@ Outside DRM Convert fbdev drivers to DRM -There are plenty of fbdev drivers for older hardware. Some hwardware has +There are plenty of fbdev drivers for older hardware. Some hardware has become obsolete, but some still provides good(-enough) framebuffers. The drivers that are still useful should be converted to DRM and afterwards removed from fbdev. -- 2.25.1
[PATCH 2/2] arm64: imx8mp: imx8mp-phycore-som enable spi nor
enable the mt25qu256aba spi nor on the imx8mp-phycore-som.
Signed-off-by: Heiko Schocher
---
.../dts/freescale/imx8mp-phycore-som.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi
b/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi
index 44a8c2337cee4..0284e7a5c6bba 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi
@@ -65,6 +65,22 @@ ethphy1: ethernet-phy@0 {
};
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_flexspi0>;
+ status = "okay";
+
+ flash0: mt25qu256aba@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <8000>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+ };
+};
+
{
clock-frequency = <40>;
pinctrl-names = "default";
@@ -217,6 +233,17 @@ MX8MP_IOMUXC_GPIO1_IO15__GPIO1_IO150x11
>;
};
+ pinctrl_flexspi0: flexspi0grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_NAND_ALE__FLEXSPI_A_SCLK 0x1c2
+ MX8MP_IOMUXC_NAND_CE0_B__FLEXSPI_A_SS0_B0x82
+ MX8MP_IOMUXC_NAND_DATA00__FLEXSPI_A_DATA00 0x82
+ MX8MP_IOMUXC_NAND_DATA01__FLEXSPI_A_DATA01 0x82
+ MX8MP_IOMUXC_NAND_DATA02__FLEXSPI_A_DATA02 0x82
+ MX8MP_IOMUXC_NAND_DATA03__FLEXSPI_A_DATA03 0x82
+ >;
+ };
+
pinctrl_i2c1: i2c1grp {
fsl,pins = <
MX8MP_IOMUXC_I2C1_SCL__I2C1_SCL 0x41c3
--
2.29.2
[PATCH 4/6] mm: Drop redundant ARCH_ENABLE_[HUGEPAGE|THP]_MIGRATION
ARCH_ENABLE_[HUGEPAGE|THP]_MIGRATION configs have duplicate definitions on platforms that subscribe them. Drop these reduntant definitions and instead just select them appropriately. Cc: Catalin Marinas Cc: Will Deacon Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Andrew Morton Cc: x...@kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux...@kvack.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Anshuman Khandual --- arch/arm64/Kconfig | 10 ++ arch/powerpc/platforms/Kconfig.cputype | 5 + arch/x86/Kconfig | 10 ++ 3 files changed, 5 insertions(+), 20 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 67e904b0f32a..c0e75f62f08c 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -11,8 +11,10 @@ config ARM64 select ACPI_PPTT if ACPI select ARCH_HAS_DEBUG_WX select ARCH_BINFMT_ELF_STATE + select ARCH_ENABLE_HUGEPAGE_MIGRATION if HUGETLB_PAGE && MIGRATION select ARCH_ENABLE_MEMORY_HOTPLUG select ARCH_ENABLE_MEMORY_HOTREMOVE + select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE select ARCH_HAS_CACHE_LINE_SIZE select ARCH_HAS_DEBUG_VIRTUAL select ARCH_HAS_DEBUG_VM_PGTABLE @@ -1903,14 +1905,6 @@ config SYSVIPC_COMPAT def_bool y depends on COMPAT && SYSVIPC -config ARCH_ENABLE_HUGEPAGE_MIGRATION - def_bool y - depends on HUGETLB_PAGE && MIGRATION - -config ARCH_ENABLE_THP_MIGRATION - def_bool y - depends on TRANSPARENT_HUGEPAGE - menu "Power management options" source "kernel/power/Kconfig" diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype index cec1017813f8..4465b71b2bff 100644 --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -96,6 +96,7 @@ config PPC_BOOK3S_64 select PPC_FPU select PPC_HAVE_PMU_SUPPORT select HAVE_ARCH_TRANSPARENT_HUGEPAGE + select ARCH_ENABLE_HUGEPAGE_MIGRATION if HUGETLB_PAGE && MIGRATION select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE select ARCH_SUPPORTS_HUGETLBFS select ARCH_SUPPORTS_NUMA_BALANCING @@ -420,10 +421,6 @@ config PPC_PKEY depends on PPC_BOOK3S_64 depends on PPC_MEM_KEYS || PPC_KUAP || PPC_KUEP -config ARCH_ENABLE_HUGEPAGE_MIGRATION - def_bool y - depends on PPC_BOOK3S_64 && HUGETLB_PAGE && MIGRATION - config PPC_MMU_NOHASH def_bool y diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 503d8b2e8676..10702ef1eb57 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -60,8 +60,10 @@ config X86 select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI select ARCH_32BIT_OFF_T if X86_32 select ARCH_CLOCKSOURCE_INIT + select ARCH_ENABLE_HUGEPAGE_MIGRATION if x86_64 && HUGETLB_PAGE && MIGRATION select ARCH_ENABLE_MEMORY_HOTPLUG if X86_64 || (X86_32 && HIGHMEM) select ARCH_ENABLE_MEMORY_HOTREMOVE if MEMORY_HOTPLUG + select ARCH_ENABLE_THP_MIGRATION if x86_64 && TRANSPARENT_HUGEPAGE select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI select ARCH_HAS_CACHE_LINE_SIZE select ARCH_HAS_DEBUG_VIRTUAL @@ -2433,14 +2435,6 @@ config ARCH_ENABLE_SPLIT_PMD_PTLOCK def_bool y depends on X86_64 || X86_PAE -config ARCH_ENABLE_HUGEPAGE_MIGRATION - def_bool y - depends on X86_64 && HUGETLB_PAGE && MIGRATION - -config ARCH_ENABLE_THP_MIGRATION - def_bool y - depends on X86_64 && TRANSPARENT_HUGEPAGE - menu "Power management and ACPI options" config ARCH_HIBERNATION_HEADER -- 2.20.1
[PATCH 3/6] mm: Generalize ARCH_ENABLE_MEMORY_[HOTPLUG|HOTREMOVE]
ARCH_ENABLE_MEMORY_[HOTPLUG|HOTREMOVE] configs have duplicate definitions on platforms that subscribe them. Instead, just make them generic options which can be selected on applicable platforms. Cc: Catalin Marinas Cc: Will Deacon Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Christian Borntraeger Cc: Yoshinori Sato Cc: Rich Felker Cc: Thomas Gleixner Cc: Ingo Molnar Cc: x...@kernel.org Cc: "H. Peter Anvin" Cc: Andrew Morton Cc: linux-arm-ker...@lists.infradead.org Cc: linux-i...@vger.kernel.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-s...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: linux...@kvack.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Anshuman Khandual --- arch/arm64/Kconfig | 8 ++-- arch/ia64/Kconfig| 8 ++-- arch/powerpc/Kconfig | 8 ++-- arch/s390/Kconfig| 8 ++-- arch/sh/Kconfig | 2 ++ arch/sh/mm/Kconfig | 8 arch/x86/Kconfig | 10 ++ mm/Kconfig | 6 ++ 8 files changed, 18 insertions(+), 40 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 68fe3b5bf17a..67e904b0f32a 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -11,6 +11,8 @@ config ARM64 select ACPI_PPTT if ACPI select ARCH_HAS_DEBUG_WX select ARCH_BINFMT_ELF_STATE + select ARCH_ENABLE_MEMORY_HOTPLUG + select ARCH_ENABLE_MEMORY_HOTREMOVE select ARCH_HAS_CACHE_LINE_SIZE select ARCH_HAS_DEBUG_VIRTUAL select ARCH_HAS_DEBUG_VM_PGTABLE @@ -305,12 +307,6 @@ config ZONE_DMA32 bool "Support DMA32 zone" if EXPERT default y -config ARCH_ENABLE_MEMORY_HOTPLUG - def_bool y - -config ARCH_ENABLE_MEMORY_HOTREMOVE - def_bool y - config SMP def_bool y diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index 2ad7a8d29fcc..96ce53ad5c9d 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -13,6 +13,8 @@ config IA64 select ARCH_MIGHT_HAVE_PC_SERIO select ACPI select ACPI_NUMA if NUMA + select ARCH_ENABLE_MEMORY_HOTPLUG + select ARCH_ENABLE_MEMORY_HOTREMOVE select ARCH_SUPPORTS_ACPI select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI @@ -250,12 +252,6 @@ config HOTPLUG_CPU can be controlled through /sys/devices/system/cpu/cpu#. Say N if you want to disable CPU hotplug. -config ARCH_ENABLE_MEMORY_HOTPLUG - def_bool y - -config ARCH_ENABLE_MEMORY_HOTREMOVE - def_bool y - config SCHED_SMT bool "SMT scheduler support" depends on SMP diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index a74c211e55b1..02a05a24659d 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -118,6 +118,8 @@ config PPC # Please keep this list sorted alphabetically. # select ARCH_32BIT_OFF_T if PPC32 + select ARCH_ENABLE_MEMORY_HOTPLUG + select ARCH_ENABLE_MEMORY_HOTREMOVE select ARCH_HAS_DEBUG_VIRTUAL select ARCH_HAS_DEVMEM_IS_ALLOWED select ARCH_HAS_ELF_RANDOMIZE @@ -515,12 +517,6 @@ config ARCH_CPU_PROBE_RELEASE def_bool y depends on HOTPLUG_CPU -config ARCH_ENABLE_MEMORY_HOTPLUG - def_bool y - -config ARCH_ENABLE_MEMORY_HOTREMOVE - def_bool y - config PPC64_SUPPORTS_MEMORY_FAILURE bool "Add support for memory hwpoison" depends on PPC_BOOK3S_64 diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index c1ff874e6c2e..f8b356550daa 100644 --- a/arch/s390/Kconfig +++ b/arch/s390/Kconfig @@ -60,6 +60,8 @@ config S390 imply IMA_SECURE_AND_OR_TRUSTED_BOOT select ARCH_32BIT_USTAT_F_TINODE select ARCH_BINFMT_ELF_STATE + select ARCH_ENABLE_MEMORY_HOTPLUG if SPARSEMEM + select ARCH_ENABLE_MEMORY_HOTREMOVE select ARCH_HAS_DEBUG_VM_PGTABLE select ARCH_HAS_DEBUG_WX select ARCH_HAS_DEVMEM_IS_ALLOWED @@ -626,12 +628,6 @@ config ARCH_SPARSEMEM_ENABLE config ARCH_SPARSEMEM_DEFAULT def_bool y -config ARCH_ENABLE_MEMORY_HOTPLUG - def_bool y if SPARSEMEM - -config ARCH_ENABLE_MEMORY_HOTREMOVE - def_bool y - config ARCH_ENABLE_SPLIT_PMD_PTLOCK def_bool y diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig index a54b0c5de37b..68129537e350 100644 --- a/arch/sh/Kconfig +++ b/arch/sh/Kconfig @@ -2,6 +2,8 @@ config SUPERH def_bool y select ARCH_32BIT_OFF_T + select ARCH_ENABLE_MEMORY_HOTPLUG if SPARSEMEM && MMU + select ARCH_ENABLE_MEMORY_HOTREMOVE if SPARSEMEM && MMU select ARCH_HAVE_CUSTOM_GPIO_H select ARCH_HAVE_NMI_SAFE_CMPXCHG if (GUSA_RB || CPU_SH4A) select ARCH_HAS_BINFMT_FLAT if !MMU diff --git a/arch/sh/mm/Kconfig b/arch/sh/mm/Kconfig index 77aa2f802d8d..d551a9cac41e 100644 --- a/arch/sh/mm/Kconfig +++ b/arch/sh/mm/Kconfig @@ -136,14 +136,6 @@ config ARCH_SPARSEMEM_DEFAULT config
[PATCH 1/2] arm64: dts: imx8mp: add flexspi node
add node for the flexspi modul on imx8mp.
Signed-off-by: Heiko Schocher
---
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index c7523fd4eae9b..086cfbbef43d7 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -36,6 +36,7 @@ aliases {
serial1 =
serial2 =
serial3 =
+ spi0 =
};
cpus {
@@ -744,6 +745,21 @@ usdhc3: mmc@30b6 {
status = "disabled";
};
+ flexspi: spi@30bb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "nxp,imx8mm-fspi";
+ reg = <0x30bb 0x1>, <0x800
0x1000>;
+ reg-names = "fspi_base", "fspi_mmap";
+ interrupts = ;
+ clocks = < IMX8MP_CLK_QSPI_ROOT>,
+< IMX8MP_CLK_QSPI_ROOT>;
+ clock-names = "fspi", "fspi_en";
+ assigned-clock-rates = <8000>;
+ assigned-clocks = < IMX8MP_CLK_QSPI>;
+ status = "disabled";
+ };
+
sdma1: dma-controller@30bd {
compatible = "fsl,imx8mp-sdma",
"fsl,imx8mq-sdma";
reg = <0x30bd 0x1>;
--
2.29.2
[PATCH 0/6] mm: some config cleanups
This series contains config cleanup patches which reduces code duplication across platforms and also improves maintainability. There is no functional change intended with this series. This has been boot tested on arm64 but only build tested on some other platforms. This applies on 5.12-rc2 Cc: x...@kernel.org Cc: linux-i...@vger.kernel.org Cc: linux-s...@vger.kernel.org Cc: linux-snps-...@lists.infradead.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-m...@vger.kernel.org Cc: linux-par...@vger.kernel.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-ri...@lists.infradead.org Cc: linux...@vger.kernel.org Cc: linux-fsde...@vger.kernel.org Cc: linux...@kvack.org Cc: linux-kernel@vger.kernel.org Anshuman Khandual (6): mm: Generalize ARCH_HAS_CACHE_LINE_SIZE mm: Generalize SYS_SUPPORTS_HUGETLBFS (rename as ARCH_SUPPORTS_HUGETLBFS) mm: Generalize ARCH_ENABLE_MEMORY_[HOTPLUG|HOTREMOVE] mm: Drop redundant ARCH_ENABLE_[HUGEPAGE|THP]_MIGRATION mm: Drop redundant ARCH_ENABLE_SPLIT_PMD_PTLOCK mm: Drop redundant HAVE_ARCH_TRANSPARENT_HUGEPAGE arch/arc/Kconfig | 9 ++-- arch/arm/Kconfig | 10 ++--- arch/arm64/Kconfig | 30 ++ arch/ia64/Kconfig | 8 ++- arch/mips/Kconfig | 6 +- arch/parisc/Kconfig| 5 + arch/powerpc/Kconfig | 11 ++ arch/powerpc/platforms/Kconfig.cputype | 16 +- arch/riscv/Kconfig | 5 + arch/s390/Kconfig | 12 +++ arch/sh/Kconfig| 7 +++--- arch/sh/mm/Kconfig | 8 --- arch/x86/Kconfig | 29 ++--- fs/Kconfig | 5 - mm/Kconfig | 9 15 files changed, 48 insertions(+), 122 deletions(-) -- 2.20.1
[PATCH 0/2] enable flexspi support on imx8mp
This series enables support for the SPI NOR on the imx8mp based phyboard-pollux-rdk board. Heiko Schocher (2): arm64: dts: imx8mp: add flexspi node arm64: imx8mp: imx8mp-phycore-som enable spi nor .../dts/freescale/imx8mp-phycore-som.dtsi | 27 +++ arch/arm64/boot/dts/freescale/imx8mp.dtsi | 16 +++ 2 files changed, 43 insertions(+) -- 2.29.2
Re: [v8 PATCH 03/13] mm: vmscan: use shrinker_rwsem to protect shrinker_maps allocation
On Tue, Feb 16, 2021 at 4:13 PM Yang Shi wrote: > > Since memcg_shrinker_map_size just can be changed under holding shrinker_rwsem > exclusively, the read side can be protected by holding read lock, so it sounds > superfluous to have a dedicated mutex. > > Kirill Tkhai suggested use write lock since: > > * We want the assignment to shrinker_maps is visible for > shrink_slab_memcg(). > * The rcu_dereference_protected() dereferrencing in shrink_slab_memcg(), but > in case of we use READ lock in alloc_shrinker_maps(), the dereferrencing > is not actually protected. > * READ lock makes alloc_shrinker_info() racy against memory allocation fail. > alloc_shrinker_info()->free_shrinker_info() may free memory right after > shrink_slab_memcg() dereferenced it. You may say > shrink_slab_memcg()->mem_cgroup_online() protects us from it? Yes, sure, > but this is not the thing we want to remember in the future, since this > spreads modularity. > > And a test with heavy paging workload didn't show write lock makes things > worse. > > Acked-by: Vlastimil Babka > Acked-by: Kirill Tkhai > Acked-by: Roman Gushchin > Signed-off-by: Yang Shi Reviewed-by: Shakeel Butt
[PATCH v4 3/4] dt-bindings: PCI: ti,j721e: Add endpoint mode dt-bindings for TI's AM64 SoC
Add endpoint mode dt-bindings for TI's AM64 SoC. This is the same IP used in J7200, however AM64 is a non-coherent architecture. Signed-off-by: Kishon Vijay Abraham I Reviewed-by: Rob Herring --- .../devicetree/bindings/pci/ti,j721e-pci-ep.yaml | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml b/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml index d06f0c4464c6..aed437dac363 100644 --- a/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml +++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml @@ -16,12 +16,14 @@ allOf: properties: compatible: oneOf: - - description: PCIe EP controller in J7200 + - const: ti,j721e-pcie-ep + - description: PCIe EP controller in AM64 items: - - const: ti,j7200-pcie-ep + - const: ti,am64-pcie-ep - const: ti,j721e-pcie-ep - - description: PCIe EP controller in J721E + - description: PCIe EP controller in J7200 items: + - const: ti,j7200-pcie-ep - const: ti,j721e-pcie-ep reg: @@ -66,7 +68,6 @@ required: - power-domains - clocks - clock-names - - dma-coherent - max-functions - phys - phy-names -- 2.17.1
[PATCH v4 0/4] AM64: Add PCIe bindings and driver support
AM64 uses the same PCIe controller as in J7200, however AM642 EVM doesn't have a clock generator (unlike J7200 base board). Here the clock from the SERDES has to be routed to the PCIE connector. This series provides an option for the pci-j721e.c driver to drive reference clock output to the connector. v1 of the patch series can be found @ [1] v2 of the patch series can be found @ [2] v3 of the patch series can be found @ [3] Changes from v3: *) Added Reviewed by from Rob *) Incorporated Krzysztof Wilczyński comment on DT binding documentation *) Fixed "warn: missing error code 'ret'" Changes from v2: *) Fix DT binding documentation suggested by Rob Changes from v1: *) Fixed missing initialization of "ret" variable in the error path. [1] -> http://lore.kernel.org/r/20201224115658.2795-1-kis...@ti.com [2] -> https://lore.kernel.org/r/20210104124103.30930-1-kis...@ti.com [3] -> https://lore.kernel.org/r/20210222114030.26445-1-kis...@ti.com Kishon Vijay Abraham I (4): dt-bindings: PCI: ti,j721e: Add binding to represent refclk to the connector dt-bindings: PCI: ti,j721e: Add host mode dt-bindings for TI's AM64 SoC dt-bindings: PCI: ti,j721e: Add endpoint mode dt-bindings for TI's AM64 SoC PCI: j721e: Add support to provide refclk to PCIe connector .../bindings/pci/ti,j721e-pci-ep.yaml | 9 .../bindings/pci/ti,j721e-pci-host.yaml | 20 - drivers/pci/controller/cadence/pci-j721e.c| 22 ++- 3 files changed, 40 insertions(+), 11 deletions(-) -- 2.17.1
[PATCH v4 4/4] PCI: j721e: Add support to provide refclk to PCIe connector
Add support to provide refclk to PCIe connector.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/pci/controller/cadence/pci-j721e.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/cadence/pci-j721e.c
b/drivers/pci/controller/cadence/pci-j721e.c
index dac1ac8a7615..7f9dd34b98a9 100644
--- a/drivers/pci/controller/cadence/pci-j721e.c
+++ b/drivers/pci/controller/cadence/pci-j721e.c
@@ -6,6 +6,7 @@
* Author: Kishon Vijay Abraham I
*/
+#include
#include
#include
#include
@@ -50,6 +51,7 @@ enum link_status {
struct j721e_pcie {
struct device *dev;
+ struct clk *refclk;
u32 mode;
u32 num_lanes;
struct cdns_pcie*cdns_pcie;
@@ -310,6 +312,7 @@ static int j721e_pcie_probe(struct platform_device *pdev)
struct cdns_pcie_ep *ep;
struct gpio_desc *gpiod;
void __iomem *base;
+ struct clk *clk;
u32 num_lanes;
u32 mode;
int ret;
@@ -408,6 +411,20 @@ static int j721e_pcie_probe(struct platform_device *pdev)
goto err_get_sync;
}
+ clk = devm_clk_get_optional(dev, "pcie_refclk");
+ if (IS_ERR(clk)) {
+ ret = PTR_ERR(clk);
+ dev_err(dev, "failed to get pcie_refclk\n");
+ goto err_pcie_setup;
+ }
+
+ ret = clk_prepare_enable(clk);
+ if (ret) {
+ dev_err(dev, "failed to enable pcie_refclk\n");
+ goto err_get_sync;
+ }
+ pcie->refclk = clk;
+
/*
* "Power Sequencing and Reset Signal Timings" table in
* PCI EXPRESS CARD ELECTROMECHANICAL SPECIFICATION, REV. 3.0
@@ -422,8 +439,10 @@ static int j721e_pcie_probe(struct platform_device *pdev)
}
ret = cdns_pcie_host_setup(rc);
- if (ret < 0)
+ if (ret < 0) {
+ clk_disable_unprepare(pcie->refclk);
goto err_pcie_setup;
+ }
break;
case PCI_MODE_EP:
@@ -476,6 +495,7 @@ static int j721e_pcie_remove(struct platform_device *pdev)
struct cdns_pcie *cdns_pcie = pcie->cdns_pcie;
struct device *dev = >dev;
+ clk_disable_unprepare(pcie->refclk);
cdns_pcie_disable_phy(cdns_pcie);
pm_runtime_put(dev);
pm_runtime_disable(dev);
--
2.17.1
[PATCH v4 1/4] dt-bindings: PCI: ti,j721e: Add binding to represent refclk to the connector
Add binding to represent refclk to the PCIe connector. Signed-off-by: Kishon Vijay Abraham I --- .../devicetree/bindings/pci/ti,j721e-pci-host.yaml | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml index 0880a613ece6..963f90816645 100644 --- a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml +++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml @@ -46,12 +46,17 @@ properties: maxItems: 1 clocks: -maxItems: 1 -description: clock-specifier to represent input to the PCIe +minItems: 1 +maxItems: 2 +description: |+ + clock-specifier to represent input to the PCIe for 1 item. + 2nd item if present represents reference clock to the connector. clock-names: +minItems: 1 items: - const: fck + - const: pcie_refclk vendor-id: const: 0x104c -- 2.17.1
[PATCH v4 2/4] dt-bindings: PCI: ti,j721e: Add host mode dt-bindings for TI's AM64 SoC
Add host mode dt-bindings for TI's AM64 SoC. This is the same IP used in J7200, however AM64 is a non-coherent architecture. Signed-off-by: Kishon Vijay Abraham I Reviewed-by: Rob Herring --- .../devicetree/bindings/pci/ti,j721e-pci-host.yaml| 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml index 963f90816645..cc900202df29 100644 --- a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml +++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml @@ -16,12 +16,14 @@ allOf: properties: compatible: oneOf: - - description: PCIe controller in J7200 + - const: ti,j721e-pcie-host + - description: PCIe controller in AM64 items: - - const: ti,j7200-pcie-host + - const: ti,am64-pcie-host - const: ti,j721e-pcie-host - - description: PCIe controller in J721E + - description: PCIe controller in J7200 items: + - const: ti,j7200-pcie-host - const: ti,j721e-pcie-host reg: @@ -67,6 +69,8 @@ properties: - const: 0xb00d - items: - const: 0xb00f + - items: + - const: 0xb010 msi-map: true @@ -83,7 +87,6 @@ required: - vendor-id - device-id - msi-map - - dma-coherent - dma-ranges - ranges - reset-gpios -- 2.17.1
[PATCH v2] usb: typec: tcpm: turn tcpm_ams_finish into void function
This function always return '0' and no callers use the return value.
So make it a void function.
This eliminates the following coccicheck warning:
./drivers/usb/typec/tcpm/tcpm.c:778:5-8: Unneeded variable: "ret".
Return "0" on line 794
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
Change in v2:
-remove the unnecessary return statement
drivers/usb/typec/tcpm/tcpm.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index be0b646..8159229 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -773,10 +773,8 @@ static enum typec_cc_status tcpm_rp_cc(struct tcpm_port
*port)
return TYPEC_CC_RP_DEF;
}
-static int tcpm_ams_finish(struct tcpm_port *port)
+static void tcpm_ams_finish(struct tcpm_port *port)
{
- int ret = 0;
-
tcpm_log(port, "AMS %s finished", tcpm_ams_str[port->ams]);
if (port->pd_capable && port->pwr_role == TYPEC_SOURCE) {
@@ -790,8 +788,6 @@ static int tcpm_ams_finish(struct tcpm_port *port)
port->in_ams = false;
port->ams = NONE_AMS;
-
- return ret;
}
static int tcpm_pd_transmit(struct tcpm_port *port,
--
1.8.3.1
Re: [PATCH] usb: typec: tcpm: turn tcpm_ams_finish into void function
On 3/7/21 10:21 PM, Yang Li wrote:
> This function always return '0' and no callers use the return value.
> So make it a void function.
>
> This eliminates the following coccicheck warning:
> ./drivers/usb/typec/tcpm/tcpm.c:778:5-8: Unneeded variable: "ret".
> Return "0" on line 794
>
> Reported-by: Abaci Robot
> Signed-off-by: Yang Li
> ---
> drivers/usb/typec/tcpm/tcpm.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index be0b646..6ee984e 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -773,10 +773,8 @@ static enum typec_cc_status tcpm_rp_cc(struct tcpm_port
> *port)
> return TYPEC_CC_RP_DEF;
> }
>
> -static int tcpm_ams_finish(struct tcpm_port *port)
> +static void tcpm_ams_finish(struct tcpm_port *port)
> {
> - int ret = 0;
> -
> tcpm_log(port, "AMS %s finished", tcpm_ams_str[port->ams]);
>
> if (port->pd_capable && port->pwr_role == TYPEC_SOURCE) {
> @@ -791,7 +789,7 @@ static int tcpm_ams_finish(struct tcpm_port *port)
> port->in_ams = false;
> port->ams = NONE_AMS;
>
> - return ret;
> + return;
Unnecessary return statement
Guenter
> }
>
> static int tcpm_pd_transmit(struct tcpm_port *port,
>
Re: [PATCH v2 5/5] mtd: spi-nor: swp: Drop 'else' after 'return'
On 06/03/21 11:50AM, Tudor Ambarus wrote: > else is not generally useful after a break or return. > > Signed-off-by: Tudor Ambarus Reviewed-by: Pratyush Yadav -- Regards, Pratyush Yadav Texas Instruments Inc.
[PATCH] kbuild: dummy-tools, support MPROFILE_KERNEL checks for ppc
ppc64le checks for -mprofile-kernel to define MPROFILE_KERNEL Kconfig. Kconfig calls arch/powerpc/tools/gcc-check-mprofile-kernel.sh for that purpose. This script performs two checks: 1) build with -mprofile-kernel should contain "_mcount" 2) build with -mprofile-kernel with a function marked as "notrace" should not produce "_mcount" So support this in dummy-tools' gcc, so that we have MPROFILE_KERNEL always true. Signed-off-by: Jiri Slaby Cc: Masahiro Yamada --- scripts/dummy-tools/gcc | 9 + 1 file changed, 9 insertions(+) diff --git a/scripts/dummy-tools/gcc b/scripts/dummy-tools/gcc index 0d0589cf8184..7b10332b23ba 100755 --- a/scripts/dummy-tools/gcc +++ b/scripts/dummy-tools/gcc @@ -73,6 +73,15 @@ if arg_contain -S "$@"; then echo "%gs" exit 0 fi + + # For arch/powerpc/tools/gcc-check-mprofile-kernel.sh + if arg_contain -m64 "$@" && arg_contain -mlittle-endian "$@" && + arg_contain -mprofile-kernel "$@"; then + if ! test -t 0 && ! grep -q notrace; then + echo "_mcount" + fi + exit 0 + fi fi # To set GCC_PLUGINS -- 2.30.1
Re: [PATCH v2 3/5] mtd: spi-nor: Get rid of duplicated argument in spi_nor_parse_sfdp()
On 06/03/21 11:50AM, Tudor Ambarus wrote:
> spi_nor_parse_sfdp(nor, nor->params);
> passes for the second argument a member within the first argument.
> Drop the second argument and obtain it directly from the first,
> and do it across all the children functions. This is a follow up for
> 'commit 69a8eed58cc0 ("mtd: spi-nor: Don't copy self-pointing struct around")'
>
> Signed-off-by: Tudor Ambarus
Reviewed-by: Pratyush Yadav
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
Re: [PATCH v1 1/1] mtd: spi-nor: intel-spi: Move platform data header to x85 subfolder
On 3/4/21 7:38 PM, Andy Shevchenko wrote:
> In order to group x86 related platform data move intel-spi.h to x85 folder.
>
> While at it, remove duplicate inclusion in C file.
>
> Signed-off-by: Andy Shevchenko
> ---
Nit, typo in $subject and commit message: s/x85/x86. Tudor may be able
to fix it locally while applying.
Apart from that
Reviewed-by: Vignesh Raghavendra
Regards
Vignesh
> drivers/mtd/spi-nor/controllers/intel-spi.c | 1 -
> drivers/mtd/spi-nor/controllers/intel-spi.h | 2 +-
> include/linux/mfd/lpc_ich.h | 2 +-
> include/linux/platform_data/{ => x86}/intel-spi.h | 0
> 4 files changed, 2 insertions(+), 3 deletions(-)
> rename include/linux/platform_data/{ => x86}/intel-spi.h (100%)
>
> diff --git a/drivers/mtd/spi-nor/controllers/intel-spi.c
> b/drivers/mtd/spi-nor/controllers/intel-spi.c
> index b54a56a68100..a413892ff449 100644
> --- a/drivers/mtd/spi-nor/controllers/intel-spi.c
> +++ b/drivers/mtd/spi-nor/controllers/intel-spi.c
> @@ -15,7 +15,6 @@
> #include
> #include
> #include
> -#include
>
> #include "intel-spi.h"
>
> diff --git a/drivers/mtd/spi-nor/controllers/intel-spi.h
> b/drivers/mtd/spi-nor/controllers/intel-spi.h
> index e2f41b8827bf..f2871179fd34 100644
> --- a/drivers/mtd/spi-nor/controllers/intel-spi.h
> +++ b/drivers/mtd/spi-nor/controllers/intel-spi.h
> @@ -9,7 +9,7 @@
> #ifndef INTEL_SPI_H
> #define INTEL_SPI_H
>
> -#include
> +#include
>
> struct intel_spi;
> struct resource;
> diff --git a/include/linux/mfd/lpc_ich.h b/include/linux/mfd/lpc_ich.h
> index 6ddca2bbb3a8..39967a5eca6d 100644
> --- a/include/linux/mfd/lpc_ich.h
> +++ b/include/linux/mfd/lpc_ich.h
> @@ -8,7 +8,7 @@
> #ifndef LPC_ICH_H
> #define LPC_ICH_H
>
> -#include
> +#include
>
> /* GPIO resources */
> #define ICH_RES_GPIO 0
> diff --git a/include/linux/platform_data/intel-spi.h
> b/include/linux/platform_data/x86/intel-spi.h
> similarity index 100%
> rename from include/linux/platform_data/intel-spi.h
> rename to include/linux/platform_data/x86/intel-spi.h
>
Re: [PATCH v2 2/5] mtd: spi-nor: core: Add vdbg msg for spi_nor_erase_multi_sectors()
On 06/03/21 11:49AM, Tudor Ambarus wrote:
> Useful when debugging non-uniform erase.
>
> Signed-off-by: Tudor Ambarus
> ---
> v2:
> - s/dev_dbg/dev_vdb
> - move vdbg message the first thing in the while
>
> drivers/mtd/spi-nor/core.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index bcaa161bc7db..498da1ec3a89 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -1610,6 +1610,9 @@ static int spi_nor_erase_multi_sectors(struct spi_nor
> *nor, u64 addr, u32 len)
> list_for_each_entry_safe(cmd, next, _list, list) {
> nor->erase_opcode = cmd->opcode;
> while (cmd->count) {
> + dev_vdbg(nor->dev, "erase_cmd->size = 0x%08x,
> erase_cmd->opcode = 0x%02x, erase_cmd->count = %d\n",
erase_cmd->count is an unsigned value (u32) so it should be %u instead
of %d.
Other than this,
Reviewed-by: Pratyush Yadav
> + cmd->size, cmd->opcode, cmd->count);
> +
> ret = spi_nor_write_enable(nor);
> if (ret)
> goto destroy_erase_cmd_list;
> --
> 2.25.1
>
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
[PATCH] usb: typec: tcpm: turn tcpm_ams_finish into void function
This function always return '0' and no callers use the return value.
So make it a void function.
This eliminates the following coccicheck warning:
./drivers/usb/typec/tcpm/tcpm.c:778:5-8: Unneeded variable: "ret".
Return "0" on line 794
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/usb/typec/tcpm/tcpm.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index be0b646..6ee984e 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -773,10 +773,8 @@ static enum typec_cc_status tcpm_rp_cc(struct tcpm_port
*port)
return TYPEC_CC_RP_DEF;
}
-static int tcpm_ams_finish(struct tcpm_port *port)
+static void tcpm_ams_finish(struct tcpm_port *port)
{
- int ret = 0;
-
tcpm_log(port, "AMS %s finished", tcpm_ams_str[port->ams]);
if (port->pd_capable && port->pwr_role == TYPEC_SOURCE) {
@@ -791,7 +789,7 @@ static int tcpm_ams_finish(struct tcpm_port *port)
port->in_ams = false;
port->ams = NONE_AMS;
- return ret;
+ return;
}
static int tcpm_pd_transmit(struct tcpm_port *port,
--
1.8.3.1
Re: [PATCH] mtd: spi-nor: use is_power_of_2()
On Sat, 6 Mar 2021 00:45:52 +0100, Michael Walle wrote: > There is already a function to check if an integer is a power of 2. Use > it. Applied to spi-nor/next, thanks! [1/1] mtd: spi-nor: use is_power_of_2() https://git.kernel.org/mtd/c/04fc298c7d08 Best regards, -- Tudor Ambarus
Re: [v8 PATCH 05/13] mm: vmscan: use kvfree_rcu instead of call_rcu
On Tue, Feb 16, 2021 at 4:13 PM Yang Shi wrote:
>
> Using kvfree_rcu() to free the old shrinker_maps instead of call_rcu().
> We don't have to define a dedicated callback for call_rcu() anymore.
>
> Signed-off-by: Yang Shi
> ---
> mm/vmscan.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 2e753c2516fa..c2a309acd86b 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -192,11 +192,6 @@ static inline int shrinker_map_size(int nr_items)
> return (DIV_ROUND_UP(nr_items, BITS_PER_LONG) * sizeof(unsigned
> long));
> }
>
> -static void free_shrinker_map_rcu(struct rcu_head *head)
> -{
> - kvfree(container_of(head, struct memcg_shrinker_map, rcu));
> -}
> -
> static int expand_one_shrinker_map(struct mem_cgroup *memcg,
>int size, int old_size)
> {
> @@ -219,7 +214,7 @@ static int expand_one_shrinker_map(struct mem_cgroup
> *memcg,
> memset((void *)new->map + old_size, 0, size - old_size);
>
> rcu_assign_pointer(memcg->nodeinfo[nid]->shrinker_map, new);
> - call_rcu(>rcu, free_shrinker_map_rcu);
> + kvfree_rcu(old);
Please use kvfree_rcu(old, rcu) instead of kvfree_rcu(old). The single
param can call synchronize_rcu().
Re: [PATCH v6 35/37] firmware: arm_scmi: make notify_priv really private
On Tue, Feb 02, 2021 at 10:15:53PM +, Cristian Marussi wrote: > Notification private data is currently accessible via handle->notify_priv; > this data was indeed meant to be private to the notification core support > and not to be accessible by SCMI drivers: make it private hiding it inside > instance descriptor struct scmi_info and accessible only via dedicated > helpers. > Patch 3 - 35 looks good to me. I need to look at last 2 patches again. So thought of replying instead of keeping you waited. You can start rebasing once we pull IIO branch from Jonathan. I will keep you posted. -- Regards, Sudeep
Re: [PATCH] mtd: spi-nor: gigadevice: Add support for gd25lb256e
On 2/9/21 1:11 PM, Md Sadre Alam wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Add support for gd25lb256e. This device tested on IPQ5018
> platform with dd from/to the flash for read/write respectly,
typo: respectly
> and mtd erase for erasing the flash.
>
> Signed-off-by: Md Sadre Alam
> ---
> drivers/mtd/spi-nor/gigadevice.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/gigadevice.c
> b/drivers/mtd/spi-nor/gigadevice.c
> index 447d84b..8f1e7ec 100644
> --- a/drivers/mtd/spi-nor/gigadevice.c
> +++ b/drivers/mtd/spi-nor/gigadevice.c
> @@ -50,6 +50,9 @@ static const struct flash_info gigadevice_parts[] = {
>SPI_NOR_4B_OPCODES | SPI_NOR_HAS_LOCK |
>SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6)
> .fixups = _fixups },
> + { "gd25lb256e", INFO(0xc86719, 0, 64 * 1024, 512,
> + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> + SPI_NOR_4B_OPCODES) },
The flash doesn't have support for 0x3b command, you can't add the
SPI_NOR_DUAL_READ flag.
I see that the flash name contains info about the generation of the flash.
Is the generation differentiated by a different device ID? If not, we can
strip the "e" from the flash name.
Looks like the flash has support for BP0-3 protection. You can try
to add the flash locking flags and test the support with mtd-utils,
if you're interested in this kind of support.
Cheers,
ta
> };
>
> const struct spi_nor_manufacturer spi_nor_gigadevice = {
> --
> 2.7.4
>
[PATCH 18/18] arm64: qcom: ipq6018: drop '0x' from unit address
Nodes need not contain '0x' for the unit address. Drop it to fix the
below warning:
arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dt.yaml: reserved-memory:
'memory@0x6' does not match any of the regexes
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/ipq6018.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/ipq6018.dtsi
b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
index 9fa5b028e4f3..23ee1bfa4318 100644
--- a/arch/arm64/boot/dts/qcom/ipq6018.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
@@ -151,7 +151,7 @@ reserved-memory {
#size-cells = <2>;
ranges;
- rpm_msg_ram: memory@0x6 {
+ rpm_msg_ram: memory@6 {
reg = <0x0 0x6 0x0 0x6000>;
no-map;
};
--
2.26.2
[PATCH 16/18] arm64: qcom: ipq8074: fix pci node reg property
reg property should be array of values, here it is a single array,
leading to below warning:
arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: soc: pci@1000:reg:0:
[268435456, 3869, 268439328, 168, 557056, 8192, 269484032, 4096] is too long
arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: soc: pci@1000:ranges:
'oneOf' conditional failed, one must be fixed:
arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: soc: pci@1000:ranges:
'oneOf' conditional failed, one must be fixed:
[[2164260864, 0, 270532608, 270532608, 0, 1048576, 2181038080, 0, 271581184,
271581184, 0, 13631488]] is not of type 'null'
[2164260864, 0, 270532608, 270532608, 0, 1048576, 2181038080, 0, 271581184,
271581184, 0, 13631488] is too long
arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: soc: pci@2000:reg:0:
[536870912, 3869, 536874784, 168, 524288, 8192, 537919488, 4096] is too long
arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: soc: pci@2000:ranges:
'oneOf' conditional failed, one must be fixed:
arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: soc: pci@2000:ranges:
'oneOf' conditional failed, one must be fixed:
[[2164260864, 0, 538968064, 538968064, 0, 1048576, 2181038080, 0, 540016640,
540016640, 0, 13631488]] is not of type 'null'
[2164260864, 0, 538968064, 538968064, 0, 1048576, 2181038080, 0, 540016640,
540016640, 0, 13631488] is too long
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/ipq8074.dtsi | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
index a32e5e79ab0b..e8db62470b23 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
@@ -567,10 +567,10 @@ frame@b128000 {
pcie1: pci@1000 {
compatible = "qcom,pcie-ipq8074";
- reg = <0x1000 0xf1d
- 0x1f20 0xa8
- 0x00088000 0x2000
- 0x1010 0x1000>;
+ reg = <0x1000 0xf1d>,
+ <0x1f20 0xa8>,
+ <0x00088000 0x2000>,
+ <0x1010 0x1000>;
reg-names = "dbi", "elbi", "parf", "config";
device_type = "pci";
linux,pci-domain = <1>;
@@ -629,10 +629,10 @@ IRQ_TYPE_LEVEL_HIGH>, /* int_c */
pcie0: pci@2000 {
compatible = "qcom,pcie-ipq8074";
- reg = <0x2000 0xf1d
- 0x2f20 0xa8
- 0x0008 0x2000
- 0x2010 0x1000>;
+ reg = <0x2000 0xf1d>,
+ <0x2f20 0xa8>,
+ <0x0008 0x2000>,
+ <0x2010 0x1000>;
reg-names = "dbi", "elbi", "parf", "config";
device_type = "pci";
linux,pci-domain = <0>;
--
2.26.2
[PATCH 17/18] arm64: qcom: sdm660: use reg value for memory node
memory node like other node should be node@reg, which is missing in this
case, so fix it up
arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: /: memory: False schema does not
allow {'device_type': ['memory'], 'reg': [[0, 1073741824, 0, 536870912]]}
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/ipq8074-hk01.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
b/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
index e8c37a1693d3..cc08dc4eb56a 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
+++ b/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
@@ -20,7 +20,7 @@ chosen {
stdout-path = "serial0";
};
- memory {
+ memory@4000 {
device_type = "memory";
reg = <0x0 0x4000 0x0 0x2000>;
};
--
2.26.2
[PATCH 15/18] arm64: qcom: sdm660: don't use empty memory node
We expect bootloader to full memory details but passing empty values
can give warning, so add a default value
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/sdm660.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm660.dtsi
b/arch/arm64/boot/dts/qcom/sdm660.dtsi
index a1133f23593a..077abcb195ce 100644
--- a/arch/arm64/boot/dts/qcom/sdm660.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm660.dtsi
@@ -208,10 +208,10 @@ scm {
};
};
- memory {
+ memory@8000 {
device_type = "memory";
/* We expect the bootloader to fill in the reg */
- reg = <0 0 0 0>;
+ reg = <0x0 0x8000 0x0 0x0>;
};
psci {
--
2.26.2
[PATCH 14/18] arm64: qcom: sdm630: don't use empty memory node
We expect bootloader to full memory details but passing empty values
can give warning, so add a default value
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/sdm630.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi
b/arch/arm64/boot/dts/qcom/sdm630.dtsi
index 5a7cf85d0cf1..23679b9e5e60 100644
--- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
@@ -311,10 +311,10 @@ scm {
};
};
- memory {
+ memory@8000 {
device_type = "memory";
/* We expect the bootloader to fill in the reg */
- reg = <0 0 0 0>;
+ reg = <0x0 0x8000 0x0 0x0>;
};
pmu {
--
2.26.2
[PATCH 11/18] arm64: qcom: sdm660: don't use underscore in node name
We have underscore (_) in node name so fix that up as well.
Fix this by changing node name to use dash (-)
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/sdm660.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm660.dtsi
b/arch/arm64/boot/dts/qcom/sdm660.dtsi
index 4abbdd03d1e7..a1133f23593a 100644
--- a/arch/arm64/boot/dts/qcom/sdm660.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm660.dtsi
@@ -16,14 +16,14 @@ / {
chosen { };
clocks {
- xo_board: xo_board {
+ xo_board: xo-board {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <1920>;
clock-output-names = "xo_board";
};
- sleep_clk: sleep_clk {
+ sleep_clk: sleep-clk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <32764>;
--
2.26.2
[PATCH 13/18] arm64: qcom: msm8998: don't use empty memory node
We expect bootloader to full memory details but passing empty values
can give warning, so add a default value
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/msm8998.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index 1f2e93aa6553..2949be4740f1 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -18,10 +18,10 @@ / {
chosen { };
- memory {
+ memory@8000 {
device_type = "memory";
/* We expect the bootloader to fill in the reg */
- reg = <0 0 0 0>;
+ reg = <0x0 0x8000 0x0 0x0>;
};
reserved-memory {
--
2.26.2
[PATCH 10/18] arm64: qcom: sdm630: don't use underscore in node name
We have underscore (_) in node name so fix that up as well.
Fix this by changing node name to use dash (-)
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/sdm630.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi
b/arch/arm64/boot/dts/qcom/sdm630.dtsi
index f91a928466c3..5a7cf85d0cf1 100644
--- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
@@ -17,14 +17,14 @@ / {
chosen { };
clocks {
- xo_board: xo_board {
+ xo_board: xo-board {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <1920>;
clock-output-names = "xo_board";
};
- sleep_clk: sleep_clk {
+ sleep_clk: sleep-clk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <32764>;
--
2.26.2
[PATCH 09/18] arm64: qcom: msm8996: don't use underscore in node name
We have underscore (_) in node name leading to warning:
arch/arm64/boot/dts/qcom/apq8096-db820c.dt.yaml: clocks: $nodename:0: 'clocks'
does not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
arch/arm64/boot/dts/qcom/apq8096-db820c.dt.yaml: clocks: xo_board: {'type':
'object'} is not allowed for {'compatible': ['fixed-clock'], '#clock-cells':
[[0]], 'clock-frequency': [[1920]], 'clock-output-names': ['xo_board'],
'phandle': [[115]]}
Fix this by changing node name to use dash (-)
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index ce430ba9c118..957487f84ead 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -17,14 +17,14 @@ / {
chosen { };
clocks {
- xo_board: xo_board {
+ xo_board: xo-board {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <1920>;
clock-output-names = "xo_board";
};
- sleep_clk: sleep_clk {
+ sleep_clk: sleep-clk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <32764>;
--
2.26.2
[PATCH 12/18] arm64: qcom: msm8996: don't use empty memory node
We expect bootloader to full memory details but passing empty values
can give warning, so add a default value
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 957487f84ead..0e2df537fb69 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -133,10 +133,10 @@ tcsr_mutex: hwlock {
#hwlock-cells = <1>;
};
- memory {
+ memory@8000 {
device_type = "memory";
/* We expect the bootloader to fill in the reg */
- reg = <0 0 0 0>;
+ reg = <0x0 0x8000 0x0 0x0>;
};
psci {
--
2.26.2
[PATCH 08/18] arm64: qcom: msm8994: don't use underscore in node name
We have underscore (_) in node name leading to warning:
arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon-cityman.dt.yaml: clocks:
xo_board: {'type': 'object'} is not allowed for {'compatible': ['fixed-clock'],
'#clock-cells': [[0]], 'clock-frequency': [[1920]], 'phandle': [[26]]}
arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon-cityman.dt.yaml: clocks:
sleep_clk: {'type': 'object'} is not allowed for {'compatible':
['fixed-clock'], '#clock-cells': [[0]], 'clock-frequency': [[32768]]}
Fix this by changing node name to use dash (-)
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/msm8994.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8994.dtsi
b/arch/arm64/boot/dts/qcom/msm8994.dtsi
index f9f0b5aa6a26..6596559a82b7 100644
--- a/arch/arm64/boot/dts/qcom/msm8994.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8994.dtsi
@@ -15,13 +15,13 @@ / {
chosen { };
clocks {
- xo_board: xo_board {
+ xo_board: xo-board {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <1920>;
};
- sleep_clk: sleep_clk {
+ sleep_clk: sleep-clk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <32768>;
--
2.26.2
[PATCH 07/18] dt-bindings: arm: qcom: Drop qcom,mtp
qcom,mtp is used msm8916-mtp.dts but not documented, it is a generic mtp
compatible and we have specfifc ones for each mtp so drop this
arch/arm64/boot/dts/qcom/msm8916-mtp.dt.yaml: /: compatible: 'oneOf'
conditional failed, one must be fixed:
['qcom,msm8916-mtp', 'qcom,msm8916-mtp/1', 'qcom,msm8916', 'qcom,mtp']
is too long
Additional items are not allowed ('qcom,msm8916', 'qcom,mtp' were
unexpected)
Additional items are not allowed ('qcom,mtp' was unexpected)
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/msm8916-mtp.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
b/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
index c3f885923127..d66c15538785 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
@@ -9,6 +9,5 @@
/ {
model = "Qualcomm Technologies, Inc. MSM 8916 MTP";
- compatible = "qcom,msm8916-mtp", "qcom,msm8916-mtp/1",
- "qcom,msm8916", "qcom,mtp";
+ compatible = "qcom,msm8916-mtp", "qcom,msm8916-mtp/1", "qcom,msm8916";
};
--
2.26.2
[PATCH 06/18] dt-bindings: arm: qcom: Document alcatel,idol347 board
Document the alcatel,idol347 board. It was missing leading to warning:
arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dt.yaml: /: compatible:
'oneOf' conditional failed, one must be fixed:
Additional items are not allowed ('qcom,msm8916' was unexpected)
Signed-off-by: Vinod Koul
---
Documentation/devicetree/bindings/arm/qcom.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml
b/Documentation/devicetree/bindings/arm/qcom.yaml
index dc87238d411b..7d97246dc379 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -125,6 +125,8 @@ properties:
- const: qcom,msm8974
- items:
+ - enum:
+ - alcatel,idol347
- const: qcom,msm8916-mtp/1
- const: qcom,msm8916-mtp
- const: qcom,msm8916
--
2.26.2
[PATCH 05/18] dt-bindings: arm: qcom: Document sony boards for apq8094
Document the various sony boards for apq8094. These are used in various sony dts files but not documented Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/arm/qcom.yaml | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 74610f1d1407..dc87238d411b 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -136,6 +136,16 @@ properties: - samsung,a5u-eur - const: qcom,msm8916 + - items: + - enum: + - sony,karin_windy + - sony,karin-row + - sony,satsuki-row + - sony,sumire-row + - sony,suzuran-row + - qcom,msm8994 + - const: qcom,apq8094 + - items: - const: qcom,msm8996-mtp -- 2.26.2
[PATCH 02/18] arm64: qcom: msm8916: don't use empty memory node
We expect bootloader to full memory details but passing empty values
gives warning, so add a default value
arch/arm64/boot/dts/qcom/apq8016-sbc.dt.yaml: /: memory:
False schema does not allow {'device_type': ['memory'], 'reg': [[0, 0,
0, 0]]}
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 5353da521974..4c155735fbc9 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -25,10 +25,10 @@ aliases {
chosen { };
- memory {
+ memory@8000 {
device_type = "memory";
/* We expect the bootloader to fill in the reg */
- reg = <0 0 0 0>;
+ reg = <0 0x8000 0 0>;
};
reserved-memory {
--
2.26.2
[PATCH 04/18] arm64: qcom: msm8994: don't use empty memory node
We expect bootloader to full memory details but passing empty values
gives warning, so add a default value
arch/arm64/boot/dts/qcom/apq8094-sony-xperia-kitakami-karin_windy.dt.yaml: /:
memory:
False schema does not allow {'device_type': ['memory'], 'reg': [[0, 0,
0, 0]]}
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/msm8994.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8994.dtsi
b/arch/arm64/boot/dts/qcom/msm8994.dtsi
index f49d442d2edf..f9f0b5aa6a26 100644
--- a/arch/arm64/boot/dts/qcom/msm8994.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8994.dtsi
@@ -149,10 +149,10 @@ scm {
};
};
- memory {
+ memory@8000 {
device_type = "memory";
/* We expect the bootloader to fill in the reg */
- reg = <0 0 0 0>;
+ reg = <0 0x8000 0 0>;
};
tcsr_mutex: hwlock {
--
2.26.2
[PATCH 01/18] arm64: qcom: apq8016-sbc: drop qcom,sbc
apq8016-sbc is one of the compaitibles for this board, but is not
documented, so drop it. This fixes these two warns:
arch/arm64/boot/dts/qcom/apq8016-sbc.dt.yaml: /: compatible:
['qcom,apq8016-sbc', 'qcom,apq8016', 'qcom,sbc']
is not valid under any of the given schemas (Possible causes of the failure):
arch/arm64/boot/dts/qcom/apq8016-sbc.dt.yaml: /: compatible:
['qcom,apq8016-sbc', 'qcom,apq8016', 'qcom,sbc'] is too long
arch/arm64/boot/dts/qcom/apq8016-sbc.dt.yaml: /: compatible:0:
'qcom,apq8016-sbc'
is not one of ['qcom,apq8064-cm-qs600', 'qcom,apq8064-ifc6410']
arch/arm64/boot/dts/qcom/apq8016-sbc.dt.yaml: /: compatible:0:
'qcom,apq8016-sbc'
is not one of ['qcom,apq8074-dragonboard']
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/apq8016-sbc.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dts
b/arch/arm64/boot/dts/qcom/apq8016-sbc.dts
index 48bd1c2874de..f3c0dbfd0a23 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dts
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dts
@@ -9,5 +9,5 @@
/ {
model = "Qualcomm Technologies, Inc. APQ 8016 SBC";
- compatible = "qcom,apq8016-sbc", "qcom,apq8016", "qcom,sbc";
+ compatible = "qcom,apq8016-sbc", "qcom,apq8016";
};
--
2.26.2
[PATCH 03/18] dt-bindings: arm: qcom: Document ipq6018-cp01 board
Document the ipq6018-cp01 board. It was missing leading to warning:
arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dt.yaml: /: compatible: 'oneOf'
conditional failed, one must be fixed:
['qcom,ipq6018-cp01', 'qcom,ipq6018'] is too short
['qcom,ipq6018-cp01', 'qcom,ipq6018'] is too long
Additional items are not allowed ('qcom,ipq6018' was unexpected)
Signed-off-by: Vinod Koul
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml
b/Documentation/devicetree/bindings/arm/qcom.yaml
index 174134f920e1..74610f1d1407 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -176,6 +176,7 @@ properties:
- items:
- enum:
+ - qcom,ipq6018-cp01
- qcom,ipq6018-cp01-c1
- const: qcom,ipq6018
--
2.26.2
[PATCH 00/18] arm64: qcom: fix dtbs_check warning
qcom dts folder shows a bunch of dtbs_check warning, this is an attempt to fix some of them. Many are due to txt binding which should be fixed when we have the yaml binding documents. Few of them are fixed as below with missing nodes names, not properly using nodes. Vinod Koul (18): arm64: qcom: apq8016-sbc: drop qcom,sbc arm64: qcom: msm8916: don't use empty memory node dt-bindings: arm: qcom: Document ipq6018-cp01 board arm64: qcom: msm8994: don't use empty memory node dt-bindings: arm: qcom: Document sony boards for apq8094 dt-bindings: arm: qcom: Document alcatel,idol347 board dt-bindings: arm: qcom: Drop qcom,mtp arm64: qcom: msm8994: don't use underscore in node name arm64: qcom: msm8996: don't use underscore in node name arm64: qcom: sdm630: don't use underscore in node name arm64: qcom: sdm660: don't use underscore in node name arm64: qcom: msm8996: don't use empty memory node arm64: qcom: msm8998: don't use empty memory node arm64: qcom: sdm630: don't use empty memory node arm64: qcom: sdm660: don't use empty memory node arm64: qcom: ipq8074: fix pci node reg property arm64: qcom: sdm660: use reg value for memory node arm64: qcom: ipq6018: drop '0x' from unit address Documentation/devicetree/bindings/arm/qcom.yaml | 13 + arch/arm64/boot/dts/qcom/apq8016-sbc.dts| 2 +- arch/arm64/boot/dts/qcom/ipq6018.dtsi | 2 +- arch/arm64/boot/dts/qcom/ipq8074-hk01.dts | 2 +- arch/arm64/boot/dts/qcom/ipq8074.dtsi | 16 arch/arm64/boot/dts/qcom/msm8916-mtp.dts| 3 +-- arch/arm64/boot/dts/qcom/msm8916.dtsi | 4 ++-- arch/arm64/boot/dts/qcom/msm8994.dtsi | 8 arch/arm64/boot/dts/qcom/msm8996.dtsi | 8 arch/arm64/boot/dts/qcom/msm8998.dtsi | 4 ++-- arch/arm64/boot/dts/qcom/sdm630.dtsi| 8 arch/arm64/boot/dts/qcom/sdm660.dtsi| 8 12 files changed, 45 insertions(+), 33 deletions(-) -- 2.26.2
linux-next: Fixes tag needs some work in the drivers-x86 tree
Hi all,
In commit
b5b5ff84fd93 ("platform/surface: aggregator: Make SSAM_DEFINE_SYNC_REQUEST_x
define static functions")
Fixes tag
Fixes: 510c8114fc74 ("platform/surface: Add platform profile driver")
has these problem(s):
- Target SHA1 does not exist
Maybe you meant
Fixes: b78b4982d763 ("platform/surface: Add platform profile driver")
--
Cheers,
Stephen Rothwell
pgpIkHmQkOn17.pgp
Description: OpenPGP digital signature
[PATCH v2] irqchip/irq-mst: Support polarity configuration
Support irq polarity configuration and save and restore the config
when system suspend and resume.
Signed-off-by: Mark-PK Tsai
---
drivers/irqchip/irq-mst-intc.c | 90 --
1 file changed, 87 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-mst-intc.c b/drivers/irqchip/irq-mst-intc.c
index 143657b0cf28..841b9b1c2699 100644
--- a/drivers/irqchip/irq-mst-intc.c
+++ b/drivers/irqchip/irq-mst-intc.c
@@ -13,15 +13,25 @@
#include
#include
#include
+#include
-#define INTC_MASK 0x0
-#define INTC_EOI 0x20
+#define INTC_MASK 0x0
+#define INTC_REV_POLARITY 0x10
+#define INTC_EOI 0x20
+
+#ifdef CONFIG_PM_SLEEP
+static LIST_HEAD(mst_intc_list);
+#endif
struct mst_intc_chip_data {
raw_spinlock_t lock;
unsigned intirq_start, nr_irqs;
void __iomem*base;
boolno_eoi;
+#ifdef CONFIG_PM_SLEEP
+ struct list_head entry;
+ u16 saved_polarity_conf[DIV_ROUND_UP(64, 16)];
+#endif
};
static void mst_set_irq(struct irq_data *d, u32 offset)
@@ -78,6 +88,19 @@ static void mst_intc_eoi_irq(struct irq_data *d)
irq_chip_eoi_parent(d);
}
+static int mst_irq_chip_set_type(struct irq_data *data, unsigned int type)
+{
+ if (type != IRQ_TYPE_LEVEL_LOW && type != IRQ_TYPE_LEVEL_HIGH)
+ return -EINVAL;
+
+ if (type == IRQ_TYPE_LEVEL_LOW) {
+ mst_set_irq(data, INTC_REV_POLARITY);
+ type = IRQ_TYPE_LEVEL_HIGH;
+ }
+
+ return irq_chip_set_type_parent(data, type);
+}
+
static struct irq_chip mst_intc_chip = {
.name = "mst-intc",
.irq_mask = mst_intc_mask_irq,
@@ -87,13 +110,62 @@ static struct irq_chip mst_intc_chip = {
.irq_set_irqchip_state = irq_chip_set_parent_state,
.irq_set_affinity = irq_chip_set_affinity_parent,
.irq_set_vcpu_affinity = irq_chip_set_vcpu_affinity_parent,
- .irq_set_type = irq_chip_set_type_parent,
+ .irq_set_type = mst_irq_chip_set_type,
.irq_retrigger = irq_chip_retrigger_hierarchy,
.flags = IRQCHIP_SET_TYPE_MASKED |
IRQCHIP_SKIP_SET_WAKE |
IRQCHIP_MASK_ON_SUSPEND,
};
+#ifdef CONFIG_PM_SLEEP
+static void mst_intc_polarity_save(struct mst_intc_chip_data *cd)
+{
+ int i;
+ void __iomem *addr = cd->base + INTC_REV_POLARITY;
+
+ for (i = 0; i < DIV_ROUND_UP(cd->nr_irqs, 16); i++)
+ cd->saved_polarity_conf[i] = readw_relaxed(addr + i * 4);
+}
+
+static void mst_intc_polarity_restore(struct mst_intc_chip_data *cd)
+{
+ int i;
+ void __iomem *addr = cd->base + INTC_REV_POLARITY;
+
+ for (i = 0; i < DIV_ROUND_UP(cd->nr_irqs, 16); i++)
+ writew_relaxed(cd->saved_polarity_conf[i], addr + i * 4);
+}
+
+static void mst_irq_resume(void)
+{
+ struct mst_intc_chip_data *cd;
+
+ list_for_each_entry(cd, _intc_list, entry)
+ mst_intc_polarity_restore(cd);
+}
+
+static int mst_irq_suspend(void)
+{
+ struct mst_intc_chip_data *cd;
+
+ list_for_each_entry(cd, _intc_list, entry)
+ mst_intc_polarity_save(cd);
+ return 0;
+}
+
+static struct syscore_ops mst_irq_syscore_ops = {
+ .suspend= mst_irq_suspend,
+ .resume = mst_irq_resume,
+};
+
+static int __init mst_irq_pm_init(void)
+{
+ register_syscore_ops(_irq_syscore_ops);
+ return 0;
+}
+late_initcall(mst_irq_pm_init);
+#endif
+
static int mst_intc_domain_translate(struct irq_domain *d,
struct irq_fwspec *fwspec,
unsigned long *hwirq,
@@ -145,6 +217,14 @@ static int mst_intc_domain_alloc(struct irq_domain
*domain, unsigned int virq,
parent_fwspec = *fwspec;
parent_fwspec.fwnode = domain->parent->fwnode;
parent_fwspec.param[1] = cd->irq_start + hwirq;
+
+ /*
+* If the irq signal is active low, configure it to active high
+* to meet GIC SPI spec in mst_irq_chip_set_type via REV_POLARITY bit
+*/
+ if (fwspec->param[2] == IRQ_TYPE_LEVEL_LOW)
+ parent_fwspec.param[2] = IRQ_TYPE_LEVEL_HIGH;
+
return irq_domain_alloc_irqs_parent(domain, virq, nr_irqs,
_fwspec);
}
@@ -193,6 +273,10 @@ static int __init mst_intc_of_init(struct device_node *dn,
return -ENOMEM;
}
+#ifdef CONFIG_PM_SLEEP
+ INIT_LIST_HEAD(>entry);
+ list_add_tail(>entry, _intc_list);
+#endif
return 0;
}
--
2.18.0
linux-next: Signed-off-by missing for commit in the rcu tree
Hi all,
Commit
3e90d423e754 ("EXP net: phy: make mdio_bus_phy_suspend/resume as
__maybe_unused")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpqnFoVCNSEx.pgp
Description: OpenPGP digital signature
Re: [PATCH v6 02/37] firmware: arm_scmi: introduce protocol handle definitions
On Tue, Feb 02, 2021 at 10:15:20PM +, Cristian Marussi wrote: > Add basic protocol handles definitions and private data helpers support. > > A protocol handle identifies a protocol instance initialized against a > specific handle; it embeds all the references to the core SCMI xfer methods > that will be needed by a protocol implementation to build and send its own > protocol specific messages using common core methods. > > As such, in the interface, a protocol handle will be passed down from the > core to the protocol specific initialization callback at init time. > > Anyway at this point only definitions are introduced, all protocols > initialization code and SCMI drivers probing is still based on the old > interface, so no functional change. > > Signed-off-by: Cristian Marussi > --- > drivers/firmware/arm_scmi/common.h | 59 ++ > drivers/firmware/arm_scmi/driver.c | 45 +++ > 2 files changed, 104 insertions(+) > [...] > diff --git a/drivers/firmware/arm_scmi/driver.c > b/drivers/firmware/arm_scmi/driver.c > index ed94efbecd61..2328a468bbd1 100644 > --- a/drivers/firmware/arm_scmi/driver.c > +++ b/drivers/firmware/arm_scmi/driver.c [...] > /** > * scmi_get_protocol_instance - Protocol initialization helper. > * @handle: A reference to the SCMI platform instance. > @@ -588,6 +629,10 @@ scmi_get_protocol_instance(struct scmi_handle *handle, > u8 protocol_id) > > pi->gid = gid; > pi->proto = proto; > + pi->handle = handle; > + pi->ph.dev = handle->dev; > + pi->ph.set_priv = scmi_set_protocol_priv; > + pi->ph.get_priv = scmi_get_protocol_priv; Sorry missed this in earlier patch. Not a must, but I prefer if you can move all these initialisation into separate functions so that scmi_get_protocol_instance can be simplified to read. if (pi) increment refcount else scmi_get_protocol alloc and init protocol instance register events How about some thing like above ? -- Regards, Sudeep
Re: [PATCH v2] mtd: spi-nor: winbond: Add support for w25q512jvq
On Mon, 8 Feb 2021 15:53:03 +0800, Shuhao Mai wrote: > Add support for w25q512jvq. This is of the same series chip with > w25q256jv, which is already supported, but with size doubled and > different JEDEC ID. > > Tested on Intel whitley platform with dd from/to the flash for > read/write respectly, and flash_erase for erasing the flash. Applied to spi-nor/next, thanks! [1/1] mtd: spi-nor: winbond: Add support for w25q512jvq https://git.kernel.org/mtd/c/ff013330fbdb Best regards, -- Tudor Ambarus
[PATCH v4 3/3] mtd: rawnand: qcom: Add support for secure regions in NAND memory
On a typical end product, a vendor may choose to secure some regions in
the NAND memory which are supposed to stay intact between FW upgrades.
The access to those regions will be blocked by a secure element like
Trustzone. So the normal world software like Linux kernel should not
touch these regions (including reading).
The regions are declared using a NAND chip DT property,
"secure-regions". So let's make use of this property and skip
access to the secure regions present in a system.
Signed-off-by: Manivannan Sadhasivam
---
drivers/mtd/nand/raw/qcom_nandc.c | 72 +++
1 file changed, 63 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/raw/qcom_nandc.c
b/drivers/mtd/nand/raw/qcom_nandc.c
index 87c23bb320bf..8027f7cb32be 100644
--- a/drivers/mtd/nand/raw/qcom_nandc.c
+++ b/drivers/mtd/nand/raw/qcom_nandc.c
@@ -431,6 +431,11 @@ struct qcom_nand_controller {
* @cfg0, cfg1, cfg0_raw..:NANDc register configurations needed for
* ecc/non-ecc mode for the current nand flash
* device
+ *
+ * @sec_regions: Array representing the secure regions in the
+ * NAND chip
+ *
+ * @nr_sec_regions:Number of secure regions in the NAND chip
*/
struct qcom_nand_host {
struct nand_chip chip;
@@ -453,6 +458,9 @@ struct qcom_nand_host {
u32 ecc_bch_cfg;
u32 clrflashstatus;
u32 clrreadstatus;
+
+ u32 *sec_regions;
+ u8 nr_sec_regions;
};
/*
@@ -662,16 +670,27 @@ static void nandc_set_reg(struct qcom_nand_controller
*nandc, int offset,
}
/* helper to configure address register values */
-static void set_address(struct qcom_nand_host *host, u16 column, int page)
+static int set_address(struct qcom_nand_host *host, u16 column, int page)
{
struct nand_chip *chip = >chip;
struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
+ u32 offs = page << chip->page_shift;
+ int i, j;
+
+ /* Skip touching the secure regions if present */
+ for (i = 0, j = 0; i < host->nr_sec_regions; i++, j += 2) {
+ if (offs >= host->sec_regions[j] &&
+ (offs <= host->sec_regions[j] + host->sec_regions[j + 1]))
+ return -EIO;
+ }
if (chip->options & NAND_BUSWIDTH_16)
column >>= 1;
nandc_set_reg(nandc, NAND_ADDR0, page << 16 | column);
nandc_set_reg(nandc, NAND_ADDR1, page >> 16 & 0xff);
+
+ return 0;
}
/*
@@ -1491,13 +1510,13 @@ static void qcom_nandc_command(struct nand_chip *chip,
unsigned int command,
WARN_ON(column != 0);
host->use_ecc = true;
- set_address(host, 0, page_addr);
+ ret = set_address(host, 0, page_addr);
update_rw_regs(host, ecc->steps, true);
break;
case NAND_CMD_SEQIN:
WARN_ON(column != 0);
- set_address(host, 0, page_addr);
+ ret = set_address(host, 0, page_addr);
break;
case NAND_CMD_PAGEPROG:
@@ -1615,7 +1634,10 @@ qcom_nandc_read_cw_raw(struct mtd_info *mtd, struct
nand_chip *chip,
host->use_ecc = false;
clear_bam_transaction(nandc);
- set_address(host, host->cw_size * cw, page);
+ ret = set_address(host, host->cw_size * cw, page);
+ if (ret)
+ return ret;
+
update_rw_regs(host, 1, true);
config_nand_page_read(nandc);
@@ -1943,7 +1965,10 @@ static int copy_last_cw(struct qcom_nand_host *host, int
page)
/* prepare a clean read buffer */
memset(nandc->data_buffer, 0xff, size);
- set_address(host, host->cw_size * (ecc->steps - 1), page);
+ ret = set_address(host, host->cw_size * (ecc->steps - 1), page);
+ if (ret)
+ return ret;
+
update_rw_regs(host, 1, true);
config_nand_single_cw_page_read(nandc, host->use_ecc);
@@ -2005,12 +2030,16 @@ static int qcom_nandc_read_oob(struct nand_chip *chip,
int page)
struct qcom_nand_host *host = to_qcom_nand_host(chip);
struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
struct nand_ecc_ctrl *ecc = >ecc;
+ int ret;
clear_read_regs(nandc);
clear_bam_transaction(nandc);
host->use_ecc = true;
- set_address(host, 0, page);
+ ret = set_address(host, 0, page);
+ if (ret)
+ return ret;
+
update_rw_regs(host, ecc->steps, true);
return read_page_ecc(host, NULL, chip->oob_poi, page);
@@ -2188,7 +2217,10 @@ static int qcom_nandc_write_oob(struct nand_chip *chip,
int page)
mtd_ooblayout_get_databytes(mtd, nandc->data_buffer + data_size, oob,
0, mtd->oobavail);
- set_address(host, host->cw_size * (ecc->steps - 1), page);
+ ret = set_address(host,
[PATCH v4 2/3] dt-bindings: mtd: Add a property to declare secure regions in NAND chips
On a typical end product, a vendor may choose to secure some regions in the NAND memory which are supposed to stay intact between FW upgrades. The access to those regions will be blocked by a secure element like Trustzone. So the normal world software like Linux kernel should not touch these regions (including reading). So let's add a property for declaring such secure regions so that the drivers can skip touching them. Signed-off-by: Manivannan Sadhasivam --- Documentation/devicetree/bindings/mtd/nand-controller.yaml | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml index d0e422f4b3e0..15a674bedca3 100644 --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml @@ -143,6 +143,13 @@ patternProperties: Ready/Busy pins. Active state refers to the NAND ready state and should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted. + secure-regions: +$ref: /schemas/types.yaml#/definitions/uint32-matrix +description: + Regions in the NAND chip which are protected using a secure element + like Trustzone. This property contains the start address and size of + the secure regions present. + required: - reg -- 2.25.1
[PATCH v4 0/3] Add support for secure regions in Qcom NANDc driver
On a typical end product, a vendor may choose to secure some regions in the NAND memory which are supposed to stay intact between FW upgrades. The access to those regions will be blocked by a secure element like Trustzone. So the normal world software like Linux kernel should not touch these regions (including reading). So this series adds a property for declaring such secure regions in DT so that the driver can skip touching them. While at it, the Qcom NANDc DT binding is also converted to YAML format. Thanks, Mani Changes in v4: * Used "uint32-matrix" instead of "uint32-array" as per Rob's review. * Collected Rob's review tag for binding conversion patch Changes in v3: * Removed the nand prefix from DT property and moved the property parsing logic before nand_scan() in driver. Changes in v2: * Moved the secure-regions property to generic NAND binding as a NAND chip property and renamed it as "nand-secure-regions". Manivannan Sadhasivam (3): dt-bindings: mtd: Convert Qcom NANDc binding to YAML dt-bindings: mtd: Add a property to declare secure regions in NAND chips mtd: rawnand: qcom: Add support for secure regions in NAND memory .../bindings/mtd/nand-controller.yaml | 7 + .../devicetree/bindings/mtd/qcom,nandc.yaml | 196 ++ .../devicetree/bindings/mtd/qcom_nandc.txt| 142 - drivers/mtd/nand/raw/qcom_nandc.c | 72 ++- 4 files changed, 266 insertions(+), 151 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/qcom,nandc.yaml delete mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt -- 2.25.1
[PATCH v4 1/3] dt-bindings: mtd: Convert Qcom NANDc binding to YAML
Convert Qcom NANDc devicetree binding to YAML.
Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Rob Herring
---
.../devicetree/bindings/mtd/qcom,nandc.yaml | 196 ++
.../devicetree/bindings/mtd/qcom_nandc.txt| 142 -
2 files changed, 196 insertions(+), 142 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/qcom,nandc.yaml
delete mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt
diff --git a/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml
b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml
new file mode 100644
index ..84ad7ff30121
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml
@@ -0,0 +1,196 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/qcom,nandc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm NAND controller
+
+maintainers:
+ - Manivannan Sadhasivam
+
+properties:
+ compatible:
+enum:
+ - qcom,ipq806x-nand
+ - qcom,ipq4019-nand
+ - qcom,ipq6018-nand
+ - qcom,ipq8074-nand
+ - qcom,sdx55-nand
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Core Clock
+ - description: Always ON Clock
+
+ clock-names:
+items:
+ - const: core
+ - const: aon
+
+ "#address-cells": true
+ "#size-cells": true
+
+patternProperties:
+ "^nand@[a-f0-9]$":
+type: object
+properties:
+ nand-bus-width:
+const: 8
+
+ nand-ecc-strength:
+enum: [1, 4, 8]
+
+ nand-ecc-step-size:
+enum:
+ - 512
+
+allOf:
+ - $ref: "nand-controller.yaml#"
+
+ - if:
+ properties:
+compatible:
+ contains:
+const: qcom,ipq806x-nand
+then:
+ properties:
+dmas:
+ items:
+- description: rxtx DMA channel
+
+dma-names:
+ items:
+- const: rxtx
+
+qcom,cmd-crci:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+Must contain the ADM command type CRCI block instance number
+specified for the NAND controller on the given platform
+
+qcom,data-crci:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+Must contain the ADM data type CRCI block instance number
+specified for the NAND controller on the given platform
+
+ - if:
+ properties:
+compatible:
+ contains:
+enum:
+ - qcom,ipq4019-nand
+ - qcom,ipq6018-nand
+ - qcom,ipq8074-nand
+ - qcom,sdx55-nand
+
+then:
+ properties:
+dmas:
+ items:
+- description: tx DMA channel
+- description: rx DMA channel
+- description: cmd DMA channel
+
+dma-names:
+ items:
+- const: tx
+- const: rx
+- const: cmd
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+nand-controller@1ac0 {
+ compatible = "qcom,ipq806x-nand";
+ reg = <0x1ac0 0x800>;
+
+ clocks = < EBI2_CLK>,
+ < EBI2_AON_CLK>;
+ clock-names = "core", "aon";
+
+ dmas = <_dma 3>;
+ dma-names = "rxtx";
+ qcom,cmd-crci = <15>;
+ qcom,data-crci = <3>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+reg = <0>;
+
+nand-ecc-strength = <4>;
+nand-bus-width = <8>;
+
+partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+label = "boot-nand";
+reg = <0 0x58a>;
+ };
+
+ partition@58a {
+label = "fs-nand";
+reg = <0x58a 0x400>;
+ };
+};
+ };
+};
+
+#include
+nand-controller@79b {
+ compatible = "qcom,ipq4019-nand";
+ reg = <0x79b 0x1000>;
+
+ clocks = < GCC_QPIC_CLK>,
+ < GCC_QPIC_AHB_CLK>;
+ clock-names = "core", "aon";
+
+ dmas = < 0>,
+ < 1>,
+ < 2>;
+ dma-names = "tx", "rx", "cmd";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+reg = <0>;
+nand-ecc-strength = <4>;
+nand-bus-width = <8>;
+
+partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+label = "boot-nand";
+reg = <0 0x58a>;
+ };
+
+ partition@58a {
+label = "fs-nand";
+reg = <0x58a 0x400>;
+ };
+};
+ };
+};
+
+...
diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
Re: [Intel-wired-lan] [PATCH] e1000e: Fix error handling in e1000_set_d0_lplu_state_82571
On 2/28/2021 11:44, Dinghao Liu wrote:
There is one e1e_wphy() call in e1000_set_d0_lplu_state_82571
that we have caught its return value but lack further handling.
Check and terminate the execution flow just like other e1e_wphy()
in this function.
Signed-off-by: Dinghao Liu
---
drivers/net/ethernet/intel/e1000e/82571.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/intel/e1000e/82571.c
b/drivers/net/ethernet/intel/e1000e/82571.c
index 88faf05e23ba..0b1e890dd583 100644
--- a/drivers/net/ethernet/intel/e1000e/82571.c
+++ b/drivers/net/ethernet/intel/e1000e/82571.c
@@ -899,6 +899,8 @@ static s32 e1000_set_d0_lplu_state_82571(struct e1000_hw
*hw, bool active)
} else {
data &= ~IGP02E1000_PM_D0_LPLU;
ret_val = e1e_wphy(hw, IGP02E1000_PHY_POWER_MGMT, data);
+ if (ret_val)
+ return ret_val;
/* LPLU and SmartSpeed are mutually exclusive. LPLU is used
* during Dx states where the power conservation is most
* important. During driver activity we should enable
Good for me.
Acked-by: Sasha Neftin
[PATCH] crypto: aegis128 - Move simd prototypes into aegis.h
On Sun, Feb 28, 2021 at 03:14:55AM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 5695e51619745d4fe3ec2506a2f0cd982c5e27a4
> commit: a4397635afea5d127548d64e0055ed471ef2d5be crypto: aegis128 - provide a
> SIMD implementation based on NEON intrinsics
> date: 1 year, 6 months ago
> config: arm64-randconfig-r035-20210226 (attached as .config)
> compiler: aarch64-linux-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> #
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a4397635afea5d127548d64e0055ed471ef2d5be
> git remote add linus
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> git fetch --no-tags linus master
> git checkout a4397635afea5d127548d64e0055ed471ef2d5be
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
> ARCH=arm64
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
>
> All warnings (new ones prefixed by >>):
>
> >> crypto/aegis128-neon.c:17:6: warning: no previous prototype for
> >> 'crypto_aegis128_have_simd' [-Wmissing-prototypes]
> 17 | bool crypto_aegis128_have_simd(void)
> | ^
---8<---
This patch fixes missing prototype warnings in crypto/aegis128-neon.c.
Fixes: a4397635afea ("crypto: aegis128 - provide a SIMD...")
Reported-by: kernel test robot
Signed-off-by: Herbert Xu
diff --git a/crypto/aegis.h b/crypto/aegis.h
index 6920ebe77679..6ef9c174c973 100644
--- a/crypto/aegis.h
+++ b/crypto/aegis.h
@@ -21,9 +21,28 @@ union aegis_block {
u8 bytes[AEGIS_BLOCK_SIZE];
};
+struct aegis_state;
+
+extern int aegis128_have_aes_insn;
+
#define AEGIS_BLOCK_ALIGN (__alignof__(union aegis_block))
#define AEGIS_ALIGNED(p) IS_ALIGNED((uintptr_t)p, AEGIS_BLOCK_ALIGN)
+bool crypto_aegis128_have_simd(void);
+void crypto_aegis128_update_simd(struct aegis_state *state, const void *msg);
+void crypto_aegis128_init_simd(struct aegis_state *state,
+ const union aegis_block *key,
+ const u8 *iv);
+void crypto_aegis128_encrypt_chunk_simd(struct aegis_state *state, u8 *dst,
+ const u8 *src, unsigned int size);
+void crypto_aegis128_decrypt_chunk_simd(struct aegis_state *state, u8 *dst,
+ const u8 *src, unsigned int size);
+int crypto_aegis128_final_simd(struct aegis_state *state,
+ union aegis_block *tag_xor,
+ unsigned int assoclen,
+ unsigned int cryptlen,
+ unsigned int authsize);
+
static __always_inline void crypto_aegis_block_xor(union aegis_block *dst,
const union aegis_block *src)
{
diff --git a/crypto/aegis128-core.c b/crypto/aegis128-core.c
index 89dc1c559689..c4f1bfa1d04f 100644
--- a/crypto/aegis128-core.c
+++ b/crypto/aegis128-core.c
@@ -58,21 +58,6 @@ static bool aegis128_do_simd(void)
return false;
}
-bool crypto_aegis128_have_simd(void);
-void crypto_aegis128_update_simd(struct aegis_state *state, const void *msg);
-void crypto_aegis128_init_simd(struct aegis_state *state,
- const union aegis_block *key,
- const u8 *iv);
-void crypto_aegis128_encrypt_chunk_simd(struct aegis_state *state, u8 *dst,
- const u8 *src, unsigned int size);
-void crypto_aegis128_decrypt_chunk_simd(struct aegis_state *state, u8 *dst,
- const u8 *src, unsigned int size);
-int crypto_aegis128_final_simd(struct aegis_state *state,
- union aegis_block *tag_xor,
- unsigned int assoclen,
- unsigned int cryptlen,
- unsigned int authsize);
-
static void crypto_aegis128_update(struct aegis_state *state)
{
union aegis_block tmp;
diff --git a/crypto/aegis128-neon.c b/crypto/aegis128-neon.c
index 94d591a002a4..a7856915ec85 100644
--- a/crypto/aegis128-neon.c
+++ b/crypto/aegis128-neon.c
@@ -30,7 +30,7 @@ bool crypto_aegis128_have_simd(void)
return IS_ENABLED(CONFIG_ARM64);
}
-void crypto_aegis128_init_simd(union aegis_block *state,
+void crypto_aegis128_init_simd(struct aegis_state *state,
const union aegis_block *key,
const u8 *iv)
{
@@ -39,14 +39,14 @@ void crypto_aegis128_init_simd(union aegis_block *state,
kernel_neon_end();
}
-void crypto_aegis128_update_simd(union
Re: linux-kernel janitorial RFP: Mark static arrays as const
On Sun, 2021-03-07 at 20:14 +0100, Julia Lawall wrote:
>
> On Wed, 3 Mar 2021, Joe Perches wrote:
>
> > On Wed, 2021-03-03 at 10:41 +0100, Rasmus Villemoes wrote:
> > > On 02/03/2021 18.42, Joe Perches wrote:
> > > > Here is a possible opportunity to reduce data usage in the kernel.
> > > >
> > > > $ git grep -P -n
> > > > '^static\s+(?!const|struct)(?:\w+\s+){1,3}\w+\s*\[\s*\]' drivers/ | \
> > > > grep -v __initdata | \
> > > > wc -l
> > > > 3250
> > > >
> > > > Meaning there are ~3000 declarations of arrays with what appears to be
> > > > file static const content that are not marked const.
> > > >
> > > > So there are many static arrays that could be marked const to move the
> > > > compiled object code from data to text minimizing the total amount of
> > > > exposed r/w data.
> > >
> > > You can add const if you like, but it will rarely change the generated
> > > code. gcc is already smart enough to take a static array whose contents
> > > are provably never modified within the TU and put it in .rodata:
> >
> > At least some or perhaps even most of the time, true, but the gcc compiler
> > from v5 through at least v10 seems inconsistent about when it does the
> > appropriate conversion.
> >
> > See the example I posted:
> > https://lore.kernel.org/lkml/6b8b250a06a98ce42120a14824531a8641f5e8aa.ca...@perches.com/
> >
> > It was a randomly chosen source file conversion btw, I had no prior
> > knowledge of whether the text/data use would change.
> >
> > I'm unsure about clang consistently moving static but provably const arrays
> > from data to text. I rarely use clang. At least for v11 it seems to be
> > better though. I didn't try 10.1.
>
> I tried the relevnt drivers in drivers/input/joystick. I got only one
> driver that changed with gcc 9.3, which was
> drivers/input/joystick/analog.c. It actually got larger:
>
> original:
>
> textdata bss dec hex filename
> 22607 10560 320 3348782cf drivers/input/joystick/analog.o
>
> after adding const:
>
> textdata bss dec hex filename
> 22728 10816 320 338648448 drivers/input/joystick/analog.o
>
> This was the only case where bss was not 0, but I don't know if there is a
> connection.
You really need consider using defconfig so whatever object code
does not have tracing/debugging support.
For instance, this code with defconfig and analog joystick:
Original:
$ size drivers/input/joystick/analog.o
textdata bss dec hex filename
8115 261 22486002198 drivers/input/joystick/analog.o
with const:
$ size drivers/input/joystick/analog.o
textdata bss dec hex filename
8179 201 2248604219c drivers/input/joystick/analog.o
[PATCH v4 06/12] arm64: dts: mediatek: mt2712: harmonize node names
This is used to fix dtbs_check warning.
Signed-off-by: Chunfeng Yun
---
v2~v4: no changes
---
arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index db17d0a4ed57..a9cca9c146fd 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -805,7 +805,7 @@
ranges;
status = "disabled";
- usb_host0: xhci@1127 {
+ usb_host0: usb@1127 {
compatible = "mediatek,mt2712-xhci",
"mediatek,mtk-xhci";
reg = <0 0x1127 0 0x1000>;
@@ -818,7 +818,7 @@
};
};
- u3phy0: usb-phy@1129 {
+ u3phy0: t-phy@1129 {
compatible = "mediatek,mt2712-tphy",
"mediatek,generic-tphy-v2";
#address-cells = <1>;
@@ -869,7 +869,7 @@
ranges;
status = "disabled";
- usb_host1: xhci@112c {
+ usb_host1: usb@112c {
compatible = "mediatek,mt2712-xhci",
"mediatek,mtk-xhci";
reg = <0 0x112c 0 0x1000>;
@@ -882,7 +882,7 @@
};
};
- u3phy1: usb-phy@112e {
+ u3phy1: t-phy@112e {
compatible = "mediatek,mt2712-tphy",
"mediatek,generic-tphy-v2";
#address-cells = <1>;
--
2.18.0
[PATCH v4 12/12] arm: dts: mt2701: harmonize node names and compatibles
This is used to fix dtbs_check warning
Signed-off-by: Chunfeng Yun
---
v2~v4: no changes
---
arch/arm/boot/dts/mt2701.dtsi | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index fade14284017..4776f85d6d5b 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -607,7 +607,7 @@
};
usb0: usb@1a1c {
- compatible = "mediatek,mt8173-xhci";
+ compatible = "mediatek,mt2701-xhci", "mediatek,mtk-xhci";
reg = <0 0x1a1c 0 0x1000>,
<0 0x1a1c4700 0 0x0100>;
reg-names = "mac", "ippc";
@@ -620,8 +620,9 @@
status = "disabled";
};
- u3phy0: usb-phy@1a1c4000 {
- compatible = "mediatek,mt2701-u3phy";
+ u3phy0: t-phy@1a1c4000 {
+ compatible = "mediatek,mt2701-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x1a1c4000 0 0x0700>;
#address-cells = <2>;
#size-cells = <2>;
@@ -646,7 +647,7 @@
};
usb1: usb@1a24 {
- compatible = "mediatek,mt8173-xhci";
+ compatible = "mediatek,mt2701-xhci", "mediatek,mtk-xhci";
reg = <0 0x1a24 0 0x1000>,
<0 0x1a244700 0 0x0100>;
reg-names = "mac", "ippc";
@@ -659,8 +660,9 @@
status = "disabled";
};
- u3phy1: usb-phy@1a244000 {
- compatible = "mediatek,mt2701-u3phy";
+ u3phy1: t-phy@1a244000 {
+ compatible = "mediatek,mt2701-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x1a244000 0 0x0700>;
#address-cells = <2>;
#size-cells = <2>;
@@ -700,8 +702,9 @@
status = "disabled";
};
- u2phy0: usb-phy@1121 {
- compatible = "mediatek,generic-tphy-v1";
+ u2phy0: t-phy@1121 {
+ compatible = "mediatek,mt2701-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x1121 0 0x0800>;
#address-cells = <2>;
#size-cells = <2>;
--
2.18.0
[PATCH v4 09/12] arm64: dts: mediatek: mt8183: fix dtbs_check warning
Harmonize node names, compatibles and properties.
Signed-off-by: Chunfeng Yun
---
v4: no changes
v3: remove property clock-names suggested by CK
v2: no changes
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 80519a145f13..8882d35ac6ab 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -880,7 +880,7 @@
ranges;
status = "disabled";
- usb_host: xhci@1120 {
+ usb_host: usb@1120 {
compatible = "mediatek,mt8183-xhci",
"mediatek,mtk-xhci";
reg = <0 0x1120 0 0x1000>;
@@ -923,11 +923,10 @@
status = "disabled";
};
- mipi_tx0: mipi-dphy@11e5 {
+ mipi_tx0: dsi-phy@11e5 {
compatible = "mediatek,mt8183-mipi-tx";
reg = <0 0x11e5 0 0x1000>;
clocks = < CLK_APMIXED_MIPID0_26M>;
- clock-names = "ref_clk";
#clock-cells = <0>;
#phy-cells = <0>;
clock-output-names = "mipi_tx0_pll";
@@ -946,11 +945,10 @@
};
};
- u3phy: usb-phy@11f4 {
+ u3phy: t-phy@11f4 {
compatible = "mediatek,mt8183-tphy",
"mediatek,generic-tphy-v2";
#address-cells = <1>;
- #phy-cells = <1>;
#size-cells = <1>;
ranges = <0 0 0x11f4 0x1000>;
status = "okay";
--
2.18.0
[PATCH v4 11/12] arm: dts: mt7623: harmonize node names and compatibles
This is used to fix dtbs_check warning
Signed-off-by: Chunfeng Yun
---
v2~v4: no changes
---
arch/arm/boot/dts/mt7623.dtsi | 26 ++
arch/arm/boot/dts/mt7623n.dtsi | 4 ++--
2 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index aea6809500d7..3c11f7cfcc40 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -787,8 +787,9 @@
};
};
- pcie0_phy: pcie-phy@1a149000 {
- compatible = "mediatek,generic-tphy-v1";
+ pcie0_phy: t-phy@1a149000 {
+ compatible = "mediatek,mt7623-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x1a149000 0 0x0700>;
#address-cells = <2>;
#size-cells = <2>;
@@ -804,8 +805,9 @@
};
};
- pcie1_phy: pcie-phy@1a14a000 {
- compatible = "mediatek,generic-tphy-v1";
+ pcie1_phy: t-phy@1a14a000 {
+ compatible = "mediatek,mt7623-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x1a14a000 0 0x0700>;
#address-cells = <2>;
#size-cells = <2>;
@@ -823,7 +825,7 @@
usb1: usb@1a1c {
compatible = "mediatek,mt7623-xhci",
-"mediatek,mt8173-xhci";
+"mediatek,mtk-xhci";
reg = <0 0x1a1c 0 0x1000>,
<0 0x1a1c4700 0 0x0100>;
reg-names = "mac", "ippc";
@@ -836,9 +838,9 @@
status = "disabled";
};
- u3phy1: usb-phy@1a1c4000 {
- compatible = "mediatek,mt7623-u3phy",
-"mediatek,mt2701-u3phy";
+ u3phy1: t-phy@1a1c4000 {
+ compatible = "mediatek,mt7623-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x1a1c4000 0 0x0700>;
#address-cells = <2>;
#size-cells = <2>;
@@ -864,7 +866,7 @@
usb2: usb@1a24 {
compatible = "mediatek,mt7623-xhci",
-"mediatek,mt8173-xhci";
+"mediatek,mtk-xhci";
reg = <0 0x1a24 0 0x1000>,
<0 0x1a244700 0 0x0100>;
reg-names = "mac", "ippc";
@@ -877,9 +879,9 @@
status = "disabled";
};
- u3phy2: usb-phy@1a244000 {
- compatible = "mediatek,mt7623-u3phy",
-"mediatek,mt2701-u3phy";
+ u3phy2: t-phy@1a244000 {
+ compatible = "mediatek,mt7623-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x1a244000 0 0x0700>;
#address-cells = <2>;
#size-cells = <2>;
diff --git a/arch/arm/boot/dts/mt7623n.dtsi b/arch/arm/boot/dts/mt7623n.dtsi
index 1880ac9e32cf..bcb0846e29fd 100644
--- a/arch/arm/boot/dts/mt7623n.dtsi
+++ b/arch/arm/boot/dts/mt7623n.dtsi
@@ -246,7 +246,7 @@
status = "disabled";
};
- mipi_tx0: mipi-dphy@1001 {
+ mipi_tx0: dsi-phy@1001 {
compatible = "mediatek,mt7623-mipi-tx",
"mediatek,mt2701-mipi-tx";
reg = <0 0x1001 0 0x90>;
@@ -265,7 +265,7 @@
status = "disabled";
};
- hdmi_phy: phy@10209100 {
+ hdmi_phy: hdmi-phy@10209100 {
compatible = "mediatek,mt7623-hdmi-phy",
"mediatek,mt2701-hdmi-phy";
reg = <0 0x10209100 0 0x24>;
--
2.18.0
[PATCH v4 05/12] arm64: dts: mediatek: mt8173: fix dtbs_check warning
Harmonize nodes names, compatibles and remove unused property.
Signed-off-by: Chunfeng Yun
---
v2~v4: no changes
---
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 4 +---
arch/arm64/boot/dts/mediatek/mt8173.dtsi| 13 +++--
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 6dffada2e66b..0ce81c4fe81e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -516,10 +516,8 @@
extcon = <_usb>;
dr_mode = "otg";
wakeup-source;
- pinctrl-names = "default", "id_float", "id_ground";
+ pinctrl-names = "default";
pinctrl-0 = <_id_pins_float>;
- pinctrl-1 = <_id_pins_float>;
- pinctrl-2 = <_id_pins_ground>;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 7fa870e4386a..75040a820f0d 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -631,7 +631,7 @@
#mbox-cells = <2>;
};
- mipi_tx0: mipi-dphy@10215000 {
+ mipi_tx0: dsi-phy@10215000 {
compatible = "mediatek,mt8173-mipi-tx";
reg = <0 0x10215000 0 0x1000>;
clocks = <>;
@@ -641,7 +641,7 @@
status = "disabled";
};
- mipi_tx1: mipi-dphy@10216000 {
+ mipi_tx1: dsi-phy@10216000 {
compatible = "mediatek,mt8173-mipi-tx";
reg = <0 0x10216000 0 0x1000>;
clocks = <>;
@@ -926,7 +926,7 @@
};
ssusb: usb@11271000 {
- compatible = "mediatek,mt8173-mtu3";
+ compatible = "mediatek,mt8173-mtu3", "mediatek,mtu3";
reg = <0 0x11271000 0 0x3000>,
<0 0x11280700 0 0x0100>;
reg-names = "mac", "ippc";
@@ -943,8 +943,9 @@
ranges;
status = "disabled";
- usb_host: xhci@1127 {
- compatible = "mediatek,mt8173-xhci";
+ usb_host: usb@1127 {
+ compatible = "mediatek,mt8173-xhci",
+"mediatek,mtk-xhci";
reg = <0 0x1127 0 0x1000>;
reg-names = "mac";
interrupts = ;
@@ -955,7 +956,7 @@
};
};
- u3phy: usb-phy@1129 {
+ u3phy: t-phy@1129 {
compatible = "mediatek,mt8173-u3phy";
reg = <0 0x1129 0 0x800>;
#address-cells = <2>;
--
2.18.0
[PATCH v4 10/12] arm: dts: mt7629: harmonize node names and compatibles
This is used to fix dtbs_check warning
Signed-off-by: Chunfeng Yun
---
v2~v4: no changes
---
arch/arm/boot/dts/mt7629.dtsi | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/mt7629.dtsi b/arch/arm/boot/dts/mt7629.dtsi
index 5cbb3d244c75..874043f0490d 100644
--- a/arch/arm/boot/dts/mt7629.dtsi
+++ b/arch/arm/boot/dts/mt7629.dtsi
@@ -329,8 +329,9 @@
status = "disabled";
};
- u3phy0: usb-phy@1a0c4000 {
- compatible = "mediatek,generic-tphy-v2";
+ u3phy0: t-phy@1a0c4000 {
+ compatible = "mediatek,mt7629-tphy",
+"mediatek,generic-tphy-v2";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x1a0c4000 0xe00>;
@@ -413,14 +414,15 @@
};
};
- pciephy1: pcie-phy@1a14a000 {
- compatible = "mediatek,generic-tphy-v2";
+ pciephy1: t-phy@1a14a000 {
+ compatible = "mediatek,mt7629-tphy",
+"mediatek,generic-tphy-v2";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x1a14a000 0x1000>;
status = "disabled";
- pcieport1: port1phy@0 {
+ pcieport1: pcie-phy@0 {
reg = <0 0x1000>;
clocks = <>;
clock-names = "ref";
--
2.18.0
[PATCH v4 08/12] arm64: dts: mediatek: mt7622: harmonize node names and compatibles
This is used to fix dtbs_check warning
Signed-off-by: Chunfeng Yun
---
v2~v4: no changes
---
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index 7c6d871538a6..890a942ec608 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -742,8 +742,8 @@
status = "disabled";
};
- u3phy: usb-phy@1a0c4000 {
- compatible = "mediatek,mt7622-u3phy",
+ u3phy: t-phy@1a0c4000 {
+ compatible = "mediatek,mt7622-tphy",
"mediatek,generic-tphy-v1";
reg = <0 0x1a0c4000 0 0x700>;
#address-cells = <2>;
@@ -877,8 +877,9 @@
status = "disabled";
};
- sata_phy: sata-phy@1a243000 {
- compatible = "mediatek,generic-tphy-v1";
+ sata_phy: t-phy@1a243000 {
+ compatible = "mediatek,mt7622-tphy",
+"mediatek,generic-tphy-v1";
#address-cells = <2>;
#size-cells = <2>;
ranges;
--
2.18.0
[PATCH v4 02/12] dt-bindings: phy: mediatek: dsi-phy: modify compatible dependence
mt7623-mipi-tx is compatible to mt2701-mipi-tx, and use "mediatek,mt2701-mipi-tx" instead on MT7623, so modify the compatible items to make dependence clear. Cc: Chun-Kuang Hu Cc: Philipp Zabel Acked-by: Chun-Kuang Hu Reviewed-by: Rob Herring Signed-off-by: Chunfeng Yun --- v4: add acked-by CK, and reviewed-by Rob v3: modify commit message suggested by CK v2: separate two patches suggested by CK --- .../devicetree/bindings/phy/mediatek,dsi-phy.yaml | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml index 71d4acea1f66..6e4d795f9b02 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml @@ -19,11 +19,14 @@ properties: pattern: "^dsi-phy@[0-9a-f]+$" compatible: -enum: - - mediatek,mt2701-mipi-tx - - mediatek,mt7623-mipi-tx - - mediatek,mt8173-mipi-tx - - mediatek,mt8183-mipi-tx +oneOf: + - items: + - enum: + - mediatek,mt7623-mipi-tx + - const: mediatek,mt2701-mipi-tx + - const: mediatek,mt2701-mipi-tx + - const: mediatek,mt8173-mipi-tx + - const: mediatek,mt8183-mipi-tx reg: maxItems: 1 -- 2.18.0
