Re: [PATCH] ARC: mm: fix spelling mistakes
On 11/9/20 5:21 AM, Flavio Suligoi wrote:
> Signed-off-by: Flavio Suligoi
Thx, applied to for-curr !
-Vineet
> ---
> arch/arc/mm/tlb.c | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arc/mm/tlb.c b/arch/arc/mm/tlb.c
> index c340acd989a0..9bb3c24f3677 100644
> --- a/arch/arc/mm/tlb.c
> +++ b/arch/arc/mm/tlb.c
> @@ -30,14 +30,14 @@
>* -Changes related to MMU v2 (Rel 4.8)
>*
>* Vineetg: Aug 29th 2008
> - * -In TLB Flush operations (Metal Fix MMU) there is a explict command to
> + * -In TLB Flush operations (Metal Fix MMU) there is a explicit command to
>*flush Micro-TLBS. If TLB Index Reg is invalid prior to TLBIVUTLB cmd,
>*it fails. Thus need to load it with ANY valid value before invoking
>*TLBIVUTLB cmd
>*
>* Vineetg: Aug 21th 2008:
>* -Reduced the duration of IRQ lockouts in TLB Flush routines
> - * -Multiple copies of TLB erase code seperated into a "single" function
> + * -Multiple copies of TLB erase code separated into a "single" function
>* -In TLB Flush routines, interrupt disabling moved UP to retrieve ASID
>* in interrupt-safe region.
>*
> @@ -66,7 +66,7 @@
>*
>* Although J-TLB is 2 way set assoc, ARC700 caches J-TLB into uTLBS which
> has
>* much higher associativity. u-D-TLB is 8 ways, u-I-TLB is 4 ways.
> - * Given this, the thrasing problem should never happen because once the 3
> + * Given this, the thrashing problem should never happen because once the 3
>* J-TLB entries are created (even though 3rd will knock out one of the prev
>* two), the u-D-TLB and u-I-TLB will have what is required to accomplish
> memcpy
>*
> @@ -127,7 +127,7 @@ static void utlb_invalidate(void)
>* There was however an obscure hardware bug, where uTLB flush would
>* fail when a prior probe for J-TLB (both totally unrelated) would
>* return lkup err - because the entry didn't exist in MMU.
> - * The Workround was to set Index reg with some valid value, prior to
> + * The Workaround was to set Index reg with some valid value, prior to
>* flush. This was fixed in MMU v3
>*/
> unsigned int idx;
> @@ -272,7 +272,7 @@ noinline void local_flush_tlb_all(void)
> }
>
> /*
> - * Flush the entrie MM for userland. The fastest way is to move to Next ASID
> + * Flush the entire MM for userland. The fastest way is to move to Next ASID
>*/
> noinline void local_flush_tlb_mm(struct mm_struct *mm)
> {
> @@ -303,7 +303,7 @@ noinline void local_flush_tlb_mm(struct mm_struct *mm)
>* Difference between this and Kernel Range Flush is
>* -Here the fastest way (if range is too large) is to move to next ASID
>* without doing any explicit Shootdown
> - * -In case of kernel Flush, entry has to be shot down explictly
> + * -In case of kernel Flush, entry has to be shot down explicitly
>*/
> void local_flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
> unsigned long end)
> @@ -620,7 +620,7 @@ void update_mmu_cache(struct vm_area_struct *vma,
> unsigned long vaddr_unaligned,
>* Super Page size is configurable in hardware (4K to 16M), but fixed once
>* RTL builds.
>*
> - * The exact THP size a Linx configuration will support is a function of:
> + * The exact THP size a Linux configuration will support is a function of:
>* - MMU page size (typical 8K, RTL fixed)
>* - software page walker address split between PGD:PTE:PFN (typical
>*11:8:13, but can be changed with 1 line)
> @@ -698,7 +698,7 @@ void local_flush_pmd_tlb_range(struct vm_area_struct
> *vma, unsigned long start,
>
> #endif
>
> -/* Read the Cache Build Confuration Registers, Decode them and save into
> +/* Read the Cache Build Configuration Registers, Decode them and save into
>* the cpuinfo structure for later use.
>* No Validation is done here, simply read/convert the BCRs
>*/
> @@ -803,13 +803,13 @@ void arc_mmu_init(void)
> pr_info("%s", arc_mmu_mumbojumbo(0, str, sizeof(str)));
>
> /*
> - * Can't be done in processor.h due to header include depenedencies
> + * Can't be done in processor.h due to header include dependencies
>*/
> BUILD_BUG_ON(!IS_ALIGNED((CONFIG_ARC_KVADDR_SIZE << 20), PMD_SIZE));
>
> /*
>* stack top size sanity check,
> - * Can't be done in processor.h due to header include depenedencies
> + * Can't be done in processor.h due to header include dependencies
>*/
> BUILD_BUG_ON(!IS_ALIGNED(STACK_TOP, PMD_SIZE));
>
> @@ -881,7 +881,7 @@ void arc_mmu_init(void)
>* the duplicate one.
>* -Knob to be verbose abt it.(TODO: hook them up to debugfs)
>*/
> -volatile int dup_pd_silent; /* Be slient abt it or complain (default) */
> +volatile int dup_pd_silent; /* Be silent abt it or complain (default) */
>
> void
Re: [PATCH] Revert "ARC: entry: fix potential EFA clobber when TIF_SYSCALL_TRACE"
On 11/9/20 2:29 AM, Greg Kroah-Hartman wrote: > On Sat, Nov 07, 2020 at 03:10:06PM +0100, Greg Kroah-Hartman wrote: >> On Fri, Nov 06, 2020 at 08:27:44PM +, Vineet Gupta wrote: >>> Hi Stable Team, >>> >>> On 10/19/20 7:19 PM, Vineet Gupta wrote: This reverts commit 00fdec98d9881bf5173af09aebd353ab3b9ac729. (but only from 5.2 and prior kernels) The original commit was a preventive fix based on code-review and was auto-picked for stable back-port (for better or worse). It was OK for v5.3+ kernels, but turned up needing an implicit change 68e5c6f073bcf70 "(ARC: entry: EV_Trap expects r10 (vs. r9) to have exception cause)" merged in v5.3 which itself was not backported. So to summarize the stable backport of this patch for v5.2 and prior kernels is busted and it won't boot. The obvious solution is backport 68e5c6f073bcf70 but that is a pain as it doesn't revert cleanly and each of affected kernels (so far v4.19, v4.14, v4.9, v4.4) needs a slightly different massaged varaint. So the easier fix is to simply revert the backport from 5.2 and prior. The issue was not a big deal as it would cause strace to sporadically not work correctly. Waldemar Brodkorb first reported this when running ARC uClibc regressions on latest stable kernels (with offending backport). Once he bisected it, the analysis was trivial, so thx to him for this. Reported-by: Waldemar Brodkorb Bisected-by: Waldemar Brodkorb Cc: stable # 5.2 and prior Signed-off-by: Vineet Gupta >>> Can this revert be please applied to 4.19 and older kernels for the next >>> cycle. >>> >>> Or is there is a procedural issue given this revert is not in mainline. I've >>> described the issue in detail above so if there's a better/desirable way of >>> reverting it from backports, please let me know. >> THis is fine, sorry, it's just in a backlog of lots of stable patches... >> >> We will get to it soon. > Now queued up, thanks. Thx a bunch Greg. -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 01/16] dt-bindings: usb: usb-hcd: Convert generic USB properties to DT schema
It seems noone is going to get involved in the discussion. Therefore I'll fix the patch in the way I suggested in my previous message. Alas I'll have to remove the reviewed-by tags of Rob from some patches. -Sergey On Mon, Oct 26, 2020 at 07:46:49PM +0300, Serge Semin wrote: > Folks, any comment on my previous message below? > > On Wed, Oct 21, 2020 at 06:46:21PM +0300, Serge Semin wrote: > > On Wed, Oct 21, 2020 at 11:00:36AM +0800, Chunfeng Yun wrote: > > > On Tue, 2020-10-20 at 14:20 +0300, Serge Semin wrote: > > > > The generic USB HCD properties have been described in the legacy > > > > bindings > > > > text file: Documentation/devicetree/bindings/usb/generic.txt . Let's > > > > convert it' content into the USB HCD DT schema properties so all USB DT > > > ^ its? > > > > nodes would be validated to have them properly utilized. > > > > > > > > Signed-off-by: Serge Semin > > > > Reviewed-by: Rob Herring > > > > > > > > --- > > > > > > > > Changelog v2: > > > > - Discard '|' in all the new properties, since we don't need to preserve > > > > the text formatting. > > > > - Convert abbreviated form of the "maximum-speed" enum restriction into > > > > the multi-lined version of the list. > > > > - Drop quotes from around the string constants. > > > > --- > > > > .../devicetree/bindings/usb/generic.txt | 57 > > > > .../devicetree/bindings/usb/usb-hcd.yaml | 88 +++ > > > > > Do we need change the file name or modify it's title? > > > the title is "Generic USB Host Controller Device Tree Bindings", but > > > some generic properties, such as, dr_mode, usb-role-switch, otg related > > > ones, are usually used by DRD controller, this may cause some confusion. > > > > Hm, good question. A problem of the naming and the properties inclusion do > > exist here. I haven't thought that through when moved all the generic > > properties into the usb-hcd.yaml bindings file. But I don't think it's a > > good > > idea to rename the file. Most likely the best solution would be to split the > > functionality up as follows: > > > > 1) usb.yaml - common USB controller with generic properties for all USB > > modes (host, peripheral, otg): > >+ $nodename > >+ phys > >+ phy-names > >+ usb-phy > >+ maximum-speed > >+ phy_type > > 2) usb-hcd.yaml - DT schema for USB host controllers (EHCI/OHCI/UHCI): > >+ allOf: [usb.yaml#] > >+ companion > > 3) usb-xhci.yaml - DT schema for USB host controllers (xHCI): > >+ allOf: [usb-hcd.yaml#] > >+ usb2-lpm-disable > >+ usb3-lpm-capable > >+ quirk-broken-port-ped > >+ imod-interval-ns > > 4) usb-drd.yaml - DT schema for USB OTG controllers: > >+ otg-rev > >+ hnp-disable > >+ srp-disable > >+ adp-disable > >+ usb-role-switch > >+ role-switch-default-mode > >+ tpl-support > >+ dr_mode: [host, peripheral, otg] > > > > So in case if an USB controller is DRD with EHCI host, then it will need > > to pass evaluation of allOf: [usb-hcd.yaml#, usb-drd.yaml#]. If an USB > > controller is DRD with xHCI host, then the next schema can be applied: > > [usb-xhci.yaml#, usb-drd.yaml#]. A conditional schema is also applicable > > here, like this: > > allOf: > > - $ref: usb-drd.yaml# > > - if: > > properties: > > dr_mode: > > const: host > > then: > > $ref: usb-hcd.yaml# (or usb-xhci.yaml#) > > else: > > #ref: usb.yaml# > > > > What do you think? @Rob, @Greg, we need your opinion here. > > > > -Sergey > > > > > > > > > 2 files changed, 88 insertions(+), 57 deletions(-) > > > > delete mode 100644 Documentation/devicetree/bindings/usb/generic.txt > > > > > > > > diff --git a/Documentation/devicetree/bindings/usb/generic.txt > > > > b/Documentation/devicetree/bindings/usb/generic.txt > > > > deleted file mode 100644 > > > > index ba472e7aefc9.. > > > > --- a/Documentation/devicetree/bindings/usb/generic.txt > > > > +++ /dev/null > > > > @@ -1,57 +0,0 @@ > > > > -Generic USB Properties > > > > - > > > > -Optional properties: > > > > - - maximum-speed: tells USB controllers we want to work up to a certain > > > > - speed. Valid arguments are "super-speed-plus", > > > > - "super-speed", "high-speed", "full-speed" and > > > > - "low-speed". In case this isn't passed via DT, > > > > USB > > > > - controllers should default to their maximum HW > > > > - capability. > > > > - - dr_mode: tells Dual-Role USB controllers that we want to work on a > > > > - particular mode. Valid arguments are "host", > > > > - "peripheral" and "otg". In case this attribute > > > > isn't > > > > - passed via DT, USB DRD controllers should > > > > default to > > > > - OTG. > > > > - - phy_type: tells USB controllers that we want
