Re: ARM: vmsplit 4g/4g

Hi Linus, On Mon, Jun 15, 2020 at 11:11:04AM +0200, Linus Walleij wrote: > OK I would be very happy to look at it so I can learn a bit about the > hands-on and general approach here. Just send it to this address > directly and I will look! Have sent it > > For the next 3 weeks, right now, i

Re: [RFC 1/3] lib: copy_{from,to}_user using gup & kmap_atomic()

Hi, On Sun, Jun 14, 2020 at 06:51:43PM +0530, afzal mohammed wrote: > It is MB/s for copying one file to another via user space buffer, i.e. > the value coreutils 'dd' shows w/ status=progress (here it was busybox > 'dd', so instead it was enabling a compile time option) Just for co

Re: [RFC 1/3] lib: copy_{from,to}_user using gup & kmap_atomic()

Hi, On Sat, Jun 13, 2020 at 10:45:33PM +0200, Arnd Bergmann wrote: > 4% boot time increase sounds like a lot, especially if that is only for > copy_from_user/copy_to_user. In the end it really depends on how well > get_user()/put_user() and small copies can be optimized in the end. i mentioned

Re: [RFC 1/3] lib: copy_{from,to}_user using gup & kmap_atomic()

Hi, On Sat, Jun 13, 2020 at 02:15:52PM +0100, Russell King - ARM Linux admin wrote: > On Sat, Jun 13, 2020 at 05:34:32PM +0530, afzal mohammed wrote: > > i think C > > library cuts any size read, write to page size (if it exceeds) & > > invokes the system call. > Yo

Re: [RFC 1/3] lib: copy_{from,to}_user using gup & kmap_atomic()

Hi, On Sat, Jun 13, 2020 at 01:56:15PM +0100, Al Viro wrote: > Incidentally, what about get_user()/put_user()? _That_ is where it's > going to really hurt... All other uaccess routines are also planned to be added, posting only copy_{from,to}_user() was to get early feedback (mentioned in the

Re: [RFC 1/3] lib: copy_{from,to}_user using gup & kmap_atomic()

Hi, On Sat, Jun 13, 2020 at 02:08:11PM +0300, Andy Shevchenko wrote: > On Fri, Jun 12, 2020 at 1:20 PM afzal mohammed > wrote: > > +// Started from arch/um/kernel/skas/uaccess.c > > Does it mean you will deduplicate it there? What i meant was, that file was taken as a templ

Re: [RFC 1/3] lib: copy_{from,to}_user using gup & kmap_atomic()

Hi, On Fri, Jun 12, 2020 at 10:07:28PM +0200, Arnd Bergmann wrote: > I think a lot > of usercopy calls are only for a few bytes, though this is of course > highly workload dependent and you might only care about the large > ones. Observation is that max. pages reaching copy_{from,to}_user() is

Re: [RFC 0/3] ARM: copy_{from,to}_user() for vmsplit 4g/4g

Hi, On Fri, Jun 12, 2020 at 09:31:12PM +0530, afzal mohammed wrote: > 512 1K 4K 16K 32K 64K 1M > > normal 30 46 89 95 90 85 65 > > uaccess_w_memcpy 28.545 85 92 91 85 65

Re: [RFC 0/3] ARM: copy_{from,to}_user() for vmsplit 4g/4g

Hi, On Fri, Jun 12, 2020 at 11:19:23AM -0400, Nicolas Pitre wrote: > On Fri, 12 Jun 2020, afzal mohammed wrote: > > Performance wise, results are not encouraging, 'dd' on tmpfs results, > Could you compare with CONFIG_UACCESS_WITH_MEMCPY as well? 512 1K

Re: [RFC 1/3] lib: copy_{from,to}_user using gup & kmap_atomic()

Hi, On Fri, Jun 12, 2020 at 02:02:13PM +0200, Arnd Bergmann wrote: > On Fri, Jun 12, 2020 at 12:18 PM afzal mohammed > wrote: > > Roughly a one-third drop in performance. Disabling highmem improves > > performance only slightly. > There are probably some things that ca

Re: ARM: vmsplit 4g/4g

Hi, On Wed, Jun 10, 2020 at 12:10:21PM +0200, Linus Walleij wrote: > On Mon, Jun 8, 2020 at 1:09 PM afzal mohammed wrote: > > Not yet. Yes, i will do the performance evaluation. > > > > i am also worried about the impact on performance as these > > [ get_user_page

[RFC 3/3] ARM: provide CONFIG_VMSPLIT_4G_DEV for development

Select UACCESS_GUP_KMAP_MEMCPY initially. Signed-off-by: afzal mohammed --- arch/arm/Kconfig | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index c77c93c485a08..ae2687679d7c8 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1326,6

[RFC 1/3] lib: copy_{from,to}_user using gup & kmap_atomic()

[1] https://lore.kernel.org/lkml/Pine.LNX.4.44.0307082332450.17252-10@localhost.localdomain/ Signed-off-by: afzal mohammed --- lib/Kconfig | 4 + lib/Makefile | 3 + lib/uaccess_gup_kmap_memcpy.c | 162 ++ 3 files changed, 16

[RFC 2/3] ARM: uaccess: let UACCESS_GUP_KMAP_MEMCPY enabling

Turn off existing raw_copy_{from,to}_user() using arm_copy_{from,to}_user() when CONFIG_UACCESS_GUP_KMAP_MEMCPY is enabled. Signed-off-by: afzal mohammed --- arch/arm/include/asm/uaccess.h | 20 arch/arm/kernel/armksyms.c | 2 ++ arch/arm/lib/Makefile | 7

[RFC 0/3] ARM: copy_{from,to}_user() for vmsplit 4g/4g

patch. Regards afzal afzal mohammed (3): lib: copy_{from,to}_user using gup & kmap_atomic() ARM: uaccess: let UACCESS_GUP_KMAP_MEMCPY enabling ARM: provide CONFIG_VMSPLIT_4G_DEV for development arch/arm/Kconfig | 9 ++ arch/arm/include/asm/uaccess.h | 20 arch/ar

Re: ARM: vmsplit 4g/4g

Hi, On Mon, Jun 08, 2020 at 08:47:27PM +0530, afzal mohammed wrote: > On Mon, Jun 08, 2020 at 04:43:57PM +0200, Arnd Bergmann wrote: > > There is another difference: get_user_pages_fast() does not return > > a vm_area_struct pointer, which is where you would check the access >

Re: ARM: vmsplit 4g/4g

Hi, On Mon, Jun 08, 2020 at 04:43:57PM +0200, Arnd Bergmann wrote: > There is another difference: get_user_pages_fast() does not return > a vm_area_struct pointer, which is where you would check the access > permissions. I suppose those pointers could not be returned to callers > that don't

Re: ARM: vmsplit 4g/4g

Hi, On Sun, Jun 07, 2020 at 09:26:26PM +0200, Arnd Bergmann wrote: > I think you have to use get_user_pages() though instead of > get_user_pages_fast(), > in order to be able to check the permission bits to prevent doing a > copy_to_user() > into read-only mappings. i was not aware of this, is

Re: ARM: vmsplit 4g/4g

Hi, [ my previous mail did not make into linux-arm-kernel mailing list, got a mail saying it has a suspicious header and that it is waiting moderator approval ] On Sun, Jun 07, 2020 at 05:11:16PM +0100, Russell King - ARM Linux admin wrote: > On Sun, Jun 07, 2020 at 06:29:32PM +0530, af

ARM: vmsplit 4g/4g

Hi, On Sat, May 16, 2020 at 09:35:57AM +0200, Arnd Bergmann wrote: > On Sat, May 16, 2020 at 8:06 AM afzal mohammed > wrote: > > Okay, so the conclusion i take is, > > 1. VMSPLIT 4G/4G have to live alongside highmem > > 2. For user space copy, do pinning followed

Re: ARM: static kernel in vmalloc space

Hi, On Thu, May 14, 2020 at 05:32:41PM +0200, Arnd Bergmann wrote: > Typical distros currently offer two kernels, with and without LPAE, > and they probably don't want to add a third one for LPAE with > either highmem or vmsplit-4g-4g. Having extra user address > space and more lowmem is both

Re: ARM: static kernel in vmalloc space

Hi, On Thu, May 14, 2020 at 07:05:45PM +0530, afzal mohammed wrote: > So if we make VMSPLIT_4G_4G, depends on !HIGH_MEMORY (w/ mention of > caveat in Kconfig help that this is meant for platforms w/ <=4GB), then > we can do copy_{from,to}_user the same way currently do, and no

Re: ARM: static kernel in vmalloc space

Hi, On Thu, May 14, 2020 at 02:41:11PM +0200, Arnd Bergmann wrote: > On Thu, May 14, 2020 at 1:18 PM afzal mohammed > wrote: > > 1. SoC w/ LPAE > > 2. TTBR1 (top 256MB) for static kernel, modules, io mappings, vmalloc, > > kmap, fixmap & vectors > R

Re: ARM: static kernel in vmalloc space

Hi, On Tue, May 12, 2020 at 09:49:59PM +0200, Arnd Bergmann wrote: > Any idea which bit you want to try next? My plan has been to next post patches for the static kernel migration to vmalloc space (currently the code is rigid, taking easy route wherever possible & not of high quality) as that

Re: ARM: static kernel in vmalloc space

Hi, On Mon, May 11, 2020 at 05:29:29PM +0200, Arnd Bergmann wrote: > What do you currently do with the module address space? In the current setup, module address space was untouched, i.e. virtual address difference b/n text & module space is far greater than 32MB, at least > (2+768+16)MB and

ARM: static kernel in vmalloc space (was Re: [PATCH 0/3] Highmem support for 32-bit RISC-V)

Hi, Kernel now boots to prompt w/ static kernel mapping moved to vmalloc space. Changes currently done have a couple of platform specific things, this has to be modified to make it multiplatform friendly (also to be taken care is ARM_PATCH_PHYS_VIRT case). Module address space has to be taken

Re: [PATCH] ARM: omap1: fix irq setup

P: replace setup_irq() by request_irq()") > Signed-off-by: Arnd Bergmann Sorry for the mistake and thanks for the fix, Acked-by: afzal mohammed Regards afzal

Re: [PATCH 0/3] Highmem support for 32-bit RISC-V

[ +linux-arm-kernel Context: This is regarding VMSPLIT_4G_4G support for 32-bit ARM as a possible replacement to highmem. For that, initially, it is being attempted to move static kernel mapping from lowmem to vmalloc space. in next reply, i will remove everyone/list !ARM related ] Hi,

Re: [PATCH 0/3] Highmem support for 32-bit RISC-V

Hi Arnd, > On Tue, Apr 14, 2020 at 09:29:46PM +0200, Arnd Bergmann wrote: > > Another thing to try early is to move the vmlinux virtual address > > from the linear mapping into vmalloc space. This does not require > > LPAE either, but it only works on relatively modern platforms that > > don't

Re: [PATCHv2 5/5] arm64: allwinner: a64: Add support for TERES-I laptop

Hi Maxime, On Sun, Mar 18, 2018 at 09:22:51PM +0100, Maxime Ripard wrote: > The first part is supposed to be the name of the boards. I did sed > s/leds/teres-i/, and applied, together with all the patches but the > PWM (so I had to drop the backlight node as well). > > Please coordinate with

Re: [PATCHv2 5/5] arm64: allwinner: a64: Add support for TERES-I laptop

Hi Maxime, On Sun, Mar 18, 2018 at 09:22:51PM +0100, Maxime Ripard wrote: > The first part is supposed to be the name of the boards. I did sed > s/leds/teres-i/, and applied, together with all the patches but the > PWM (so I had to drop the backlight node as well). > > Please coordinate with

Re: [PATCHv2 5/5] arm64: allwinner: a64: Add support for TERES-I laptop

Hi, On Fri, Mar 16, 2018 at 12:07:53PM +0530, afzal mohammed wrote: > Received only patch 4 & 5 in my inbox, receive path was via > linux-kernel rather than linux-arm-kernel, but in both archives all > patches are seen (though threading seems not right), probably missing >

Re: [PATCHv2 5/5] arm64: allwinner: a64: Add support for TERES-I laptop

Hi, On Fri, Mar 16, 2018 at 12:07:53PM +0530, afzal mohammed wrote: > Received only patch 4 & 5 in my inbox, receive path was via > linux-kernel rather than linux-arm-kernel, but in both archives all > patches are seen (though threading seems not right), probably missing >

Re: [PATCHv2 5/5] arm64: allwinner: a64: Add support for TERES-I laptop

have with LKML, so had to pull the series from patchwork, for the series, Tested-by: afzal mohammed <afzal.mohd...@gmail.com> afzal

Re: [PATCHv2 5/5] arm64: allwinner: a64: Add support for TERES-I laptop

the series from patchwork, for the series, Tested-by: afzal mohammed afzal

Re: arm64: allwinner: Add support for TERES I laptop

Hi, On Thu, Mar 15, 2018 at 10:36:06PM +0530, afzal mohammed wrote: > Thanks for the patches > > w/ defconfig could reach to prompt via serial console using audio > jack. > > And just by enabling PWM_SUN4I & FB_SIMPLE, laptop could function > standalone as well. &g

Re: arm64: allwinner: Add support for TERES I laptop

Hi, On Thu, Mar 15, 2018 at 10:36:06PM +0530, afzal mohammed wrote: > Thanks for the patches > > w/ defconfig could reach to prompt via serial console using audio > jack. > > And just by enabling PWM_SUN4I & FB_SIMPLE, laptop could function > standalone as well. &g

Re: [PATCH 00/16] remove eight obsolete architectures

Hi, On Thu, Mar 15, 2018 at 10:56:48AM +0100, Arnd Bergmann wrote: > On Thu, Mar 15, 2018 at 10:42 AM, David Howells wrote: > > Do we have anything left that still implements NOMMU? Please don't kill !MMU. > Yes, plenty. > I've made an overview of the remaining

Re: [PATCH 00/16] remove eight obsolete architectures

Hi, On Thu, Mar 15, 2018 at 10:56:48AM +0100, Arnd Bergmann wrote: > On Thu, Mar 15, 2018 at 10:42 AM, David Howells wrote: > > Do we have anything left that still implements NOMMU? Please don't kill !MMU. > Yes, plenty. > I've made an overview of the remaining architectures for my own

Re: arm64: allwinner: Add support for TERES I laptop

Hi, On Mon, Mar 12, 2018 at 04:10:45PM +, Harald Geyer wrote: > This series adds support for the TERES I open hardware laptop produced > by olimex. With these patches and a bootloader capable of setting up > simple framebuffer the laptop is quite useable. Thanks for the patches w/ defconfig

Re: arm64: allwinner: Add support for TERES I laptop

Hi, On Mon, Mar 12, 2018 at 04:10:45PM +, Harald Geyer wrote: > This series adds support for the TERES I open hardware laptop produced > by olimex. With these patches and a bootloader capable of setting up > simple framebuffer the laptop is quite useable. Thanks for the patches w/ defconfig

Re: [tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware

Hi, On Sun, Feb 11, 2018 at 11:19:10AM -0800, tip-bot for David Woodhouse wrote: > x86/speculation: Use IBRS if available before calling into firmware > > Retpoline means the kernel is safe because it has no indirect branches. > But firmware isn't, so use IBRS for firmware calls if it's

Re: [tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware

Hi, On Sun, Feb 11, 2018 at 11:19:10AM -0800, tip-bot for David Woodhouse wrote: > x86/speculation: Use IBRS if available before calling into firmware > > Retpoline means the kernel is safe because it has no indirect branches. > But firmware isn't, so use IBRS for firmware calls if it's

Re: [PATCH] doc: memory-barriers: reStructure Text

Hi, On Thu, Jan 04, 2018 at 11:27:55AM +0100, Markus Heiser wrote: > IMO symlinks are mostly ending in a mess, URLs are never stable. > There is a > > https://www.kernel.org/doc/html/latest/objects.inv > > to handle such requirements. Take a look at *intersphinx* : > >

Re: [PATCH] doc: memory-barriers: reStructure Text

Hi, On Thu, Jan 04, 2018 at 11:27:55AM +0100, Markus Heiser wrote: > IMO symlinks are mostly ending in a mess, URLs are never stable. > There is a > > https://www.kernel.org/doc/html/latest/objects.inv > > to handle such requirements. Take a look at *intersphinx* : > >

Re: [PATCH] doc: memory-barriers: reStructure Text

Hi, On Thu, Jan 04, 2018 at 09:48:50AM +0800, Boqun Feng wrote: > > The location chosen is "Documentation/kernel-hacking", i was unsure > > where this should reside & there was no .rst file in top-level directory > > "Documentation", so put it into one of the existing folder that seemed > > to

Re: [PATCH] doc: memory-barriers: reStructure Text

Hi, On Thu, Jan 04, 2018 at 09:48:50AM +0800, Boqun Feng wrote: > > The location chosen is "Documentation/kernel-hacking", i was unsure > > where this should reside & there was no .rst file in top-level directory > > "Documentation", so put it into one of the existing folder that seemed > > to

Re: [PATCH] doc: memory-barriers: reStructure Text

Hi, On Thu, Jan 04, 2018 at 12:48:28AM +0100, Peter Zijlstra wrote: > > Let PDF & HTML's be created out of memory-barriers Text by > > reStructuring. > So I hate this rst crap with a passion, so NAK from me. Okay, the outcome is exactly as was feared. Abondoning the patch, let this be >

Re: [PATCH] doc: memory-barriers: reStructure Text

Hi, On Thu, Jan 04, 2018 at 12:48:28AM +0100, Peter Zijlstra wrote: > > Let PDF & HTML's be created out of memory-barriers Text by > > reStructuring. > So I hate this rst crap with a passion, so NAK from me. Okay, the outcome is exactly as was feared. Abondoning the patch, let this be >

[PATCH] doc: memory-barriers: reStructure Text

be cross-linked Signed-off-by: afzal mohammed <afzal.mohd...@gmail.com> --- Hi, With this change, pdf & html could be generated. There certainly are improvements to be made, but thought of first knowing whether migrating memory-barriers from txt to rst is welcome. The location chosen is

[PATCH] doc: memory-barriers: reStructure Text

be cross-linked Signed-off-by: afzal mohammed --- Hi, With this change, pdf & html could be generated. There certainly are improvements to be made, but thought of first knowing whether migrating memory-barriers from txt to rst is welcome. The location chosen is "Documentation/kernel-h

Re: Prototype patch for Linux-kernel memory model

Hi, On Fri, Dec 22, 2017 at 09:41:32AM +0530, afzal mohammed wrote: > On Thu, Dec 21, 2017 at 08:15:02AM -0800, Paul E. McKenney wrote: > > Have you installed and run the herd tool? Doing so would allow you > > to experiment with changes to the litmus tests. > > Yes,

Re: Prototype patch for Linux-kernel memory model

Hi, On Fri, Dec 22, 2017 at 09:41:32AM +0530, afzal mohammed wrote: > On Thu, Dec 21, 2017 at 08:15:02AM -0800, Paul E. McKenney wrote: > > Have you installed and run the herd tool? Doing so would allow you > > to experiment with changes to the litmus tests. > > Yes,

Re: Prototype patch for Linux-kernel memory model

Hi, On Thu, Dec 21, 2017 at 08:15:02AM -0800, Paul E. McKenney wrote: > On Thu, Dec 21, 2017 at 09:00:55AM +0530, afzal mohammed wrote: > > Since it is now mentioned that r1 can have final value of 0, though it > > is understood, it might make things crystal clear a

Re: Prototype patch for Linux-kernel memory model

Hi, On Thu, Dec 21, 2017 at 08:15:02AM -0800, Paul E. McKenney wrote: > On Thu, Dec 21, 2017 at 09:00:55AM +0530, afzal mohammed wrote: > > Since it is now mentioned that r1 can have final value of 0, though it > > is understood, it might make things crystal clear a

Re: Prototype patch for Linux-kernel memory model

Hi, On Wed, Dec 20, 2017 at 08:45:38AM -0800, Paul E. McKenney wrote: > On Wed, Dec 20, 2017 at 05:01:45PM +0530, afzal mohammed wrote: > > > +It is tempting to assume that CPU0()'s store to x is globally ordered > > > +before CPU1()'s store to z, but this is not the case: &

Re: Prototype patch for Linux-kernel memory model

Hi, On Wed, Dec 20, 2017 at 08:45:38AM -0800, Paul E. McKenney wrote: > On Wed, Dec 20, 2017 at 05:01:45PM +0530, afzal mohammed wrote: > > > +It is tempting to assume that CPU0()'s store to x is globally ordered > > > +before CPU1()'s store to z, but this is not the case: &

Re: Prototype patch for Linux-kernel memory model

Hi, Is this patch not destined to the HEAD of Torvalds ?, got that feeling as this was in flight around merge window & have not yet made there. On Wed, Nov 15, 2017 at 08:37:49AM -0800, Paul E. McKenney wrote: > diff --git a/tools/memory-model/Documentation/recipes.txt >

Re: Prototype patch for Linux-kernel memory model

Hi, Is this patch not destined to the HEAD of Torvalds ?, got that feeling as this was in flight around merge window & have not yet made there. On Wed, Nov 15, 2017 at 08:37:49AM -0800, Paul E. McKenney wrote: > diff --git a/tools/memory-model/Documentation/recipes.txt >

Re: Prototype patch for Linux-kernel memory model

Hi, A trivial & late (sorry) comment, On Wed, Nov 15, 2017 at 08:37:49AM -0800, Paul E. McKenney wrote: > +THE HAPPENS-BEFORE RELATION: hb > +--- > +Less trivial examples of prop all involve fences. Unlike the simple > +examples above, they can require that some

Re: Prototype patch for Linux-kernel memory model

Hi, A trivial & late (sorry) comment, On Wed, Nov 15, 2017 at 08:37:49AM -0800, Paul E. McKenney wrote: > +THE HAPPENS-BEFORE RELATION: hb > +--- > +Less trivial examples of prop all involve fences. Unlike the simple > +examples above, they can require that some

Re: [PATCH 1/6] ARM: stm32: prepare stm32 family to welcome armv7 architecture

Hi, On Mon, Dec 11, 2017 at 02:40:43PM +0100, Arnd Bergmann wrote: > On Mon, Dec 11, 2017 at 11:25 AM, Linus Walleij > >> This patch prepares the STM32 machine for the integration of Cortex-A > >> based microprocessor (MPU), on top of the existing Cortex-M > >> microcontroller family (MCU).

Re: [PATCH 1/6] ARM: stm32: prepare stm32 family to welcome armv7 architecture

Hi, On Mon, Dec 11, 2017 at 02:40:43PM +0100, Arnd Bergmann wrote: > On Mon, Dec 11, 2017 at 11:25 AM, Linus Walleij > >> This patch prepares the STM32 machine for the integration of Cortex-A > >> based microprocessor (MPU), on top of the existing Cortex-M > >> microcontroller family (MCU).

Re: vger.kernel.org mail queue issue?

Hi, On Mon, May 01, 2017 at 10:50:57AM -0400, David Miller wrote: > From: afzal mohammed <afzal.mohd...@gmail.com> > > On Wed, Jan 11, 2017 at 09:07:35PM -0500, David Miller wrote: > >> From: Florian Fainelli <f.faine...@gmail.com> > >> > I am s

Re: vger.kernel.org mail queue issue?

Hi, On Mon, May 01, 2017 at 10:50:57AM -0400, David Miller wrote: > From: afzal mohammed > > On Wed, Jan 11, 2017 at 09:07:35PM -0500, David Miller wrote: > >> From: Florian Fainelli > >> > I am seeing emails being received right now from @vger.kernel.o

Re: vger.kernel.org mail queue issue?

Hi, On Wed, Jan 11, 2017 at 09:07:35PM -0500, David Miller wrote: > From: Florian Fainelli > > I am seeing emails being received right now from @vger.kernel.org that > > seem to be from this morning according to my mailer. Has anything > > changed on vger.kernel.org that

Re: vger.kernel.org mail queue issue?

Hi, On Wed, Jan 11, 2017 at 09:07:35PM -0500, David Miller wrote: > From: Florian Fainelli > > I am seeing emails being received right now from @vger.kernel.org that > > seem to be from this morning according to my mailer. Has anything > > changed on vger.kernel.org that could cause that? Other

Re: [PATCH] ARM: nommu: access ID_PFR1 only if CPUID scheme

Hi, On Thu, Mar 23, 2017 at 09:37:48PM +1000, Greg Ungerer wrote: > Tested-by: Greg Ungerer Thanks Greg Since there was no negative feedback yet, change has been deposited in rmk's patch system as 8665/1 Regards afzal

Re: [PATCH] ARM: nommu: access ID_PFR1 only if CPUID scheme

Hi, On Thu, Mar 23, 2017 at 09:37:48PM +1000, Greg Ungerer wrote: > Tested-by: Greg Ungerer Thanks Greg Since there was no negative feedback yet, change has been deposited in rmk's patch system as 8665/1 Regards afzal

Re: [PATCH] ARM: nommu: access ID_PFR1 only if CPUID scheme

Hi, On Fri, Mar 17, 2017 at 10:10:34PM +0530, afzal mohammed wrote: > Greg upon trying to boot no-MMU Kernel on ARM926EJ reported boot > failure. He root caused it to ID_PFR1 access introduced by the > commit mentioned in the fixes tag below. > > All CP15 processors need not

Re: [PATCH] ARM: nommu: access ID_PFR1 only if CPUID scheme

Hi, On Fri, Mar 17, 2017 at 10:10:34PM +0530, afzal mohammed wrote: > Greg upon trying to boot no-MMU Kernel on ARM926EJ reported boot > failure. He root caused it to ID_PFR1 access introduced by the > commit mentioned in the fixes tag below. > > All CP15 processors need not

[PATCH] ARM: nommu: access ID_PFR1 only if CPUID scheme

it. Hence check for it before accessing processor feature register, ID_PFR1. Fixes: f8300a0b5de0 ("ARM: 8647/2: nommu: dynamic exception base address setting") Reported-by: Greg Ungerer <g...@uclinux.org> Signed-off-by: afzal mohammed <afzal.mohd...@gmail.com> --- Hi Russell, It

[PATCH] ARM: nommu: access ID_PFR1 only if CPUID scheme

it. Hence check for it before accessing processor feature register, ID_PFR1. Fixes: f8300a0b5de0 ("ARM: 8647/2: nommu: dynamic exception base address setting") Reported-by: Greg Ungerer Signed-off-by: afzal mohammed --- Hi Russell, It would be good to have the fix go in during -rc, as,

Re: [PATCH RESEND] ARM: ep93xx: Disable TS-72xx watchdog before uncompressing

Hi, On Thu, Feb 02, 2017 at 12:12:26PM -0800, Florian Fainelli wrote: > The TS-72xx/73xx boards have a CPLD watchdog which is configured to > reset the board after 8 seconds, if the kernel is large enough that this > takes about this time to decompress the kernel, we will encounter a > spurious

Re: [PATCH RESEND] ARM: ep93xx: Disable TS-72xx watchdog before uncompressing

Hi, On Thu, Feb 02, 2017 at 12:12:26PM -0800, Florian Fainelli wrote: > The TS-72xx/73xx boards have a CPLD watchdog which is configured to > reset the board after 8 seconds, if the kernel is large enough that this > takes about this time to decompress the kernel, we will encounter a > spurious

Re: [PATCH v3 0/3] ARM: !MMU: v7-A support, dynamic vectors base handling

Hi, On Wed, Feb 01, 2017 at 10:33:17AM +, Vladimir Murzin wrote: > On 31/01/17 19:24, Russell King - ARM Linux wrote: > > On Tue, Jan 31, 2017 at 06:34:46PM +0530, afzal mohammed wrote: > >> ARM core changes to support !MMU Kernel on v7-A MMU processors. > >> >

Re: [PATCH v3 0/3] ARM: !MMU: v7-A support, dynamic vectors base handling

Hi, On Wed, Feb 01, 2017 at 10:33:17AM +, Vladimir Murzin wrote: > On 31/01/17 19:24, Russell King - ARM Linux wrote: > > On Tue, Jan 31, 2017 at 06:34:46PM +0530, afzal mohammed wrote: > >> ARM core changes to support !MMU Kernel on v7-A MMU processors. > >> >

[PATCH v3 2/3] ARM: nommu: display vectors base

.uk> Signed-off-by: afzal mohammed <afzal.mohd...@gmail.com> --- v3: Simplify by defining VECTORS_BASE to vectors_base v2: A change to accomodate bisectability resolution on patch 1/4 arch/arm/include/asm/memory.h | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --gi

[PATCH v3 2/3] ARM: nommu: display vectors base

VECTORS_BASE displays the exception base address. Now on no-MMU as the exception base address is dynamically estimated, define VECTORS_BASE to the variable holding it. As it is the case, limit VECTORS_BASE constant definition to MMU. Suggested-by: Russell King Signed-off-by: afzal mohammed

[PATCH v3 3/3] ARM: nommu: remove Hivecs configuration is asm

Now that exception based address is handled dynamically for processors with CP15, remove Hivecs configuration in assembly. Signed-off-by: afzal mohammed <afzal.mohd...@gmail.com> Tested-by: Vladimir Murzin <vladimir.mur...@arm.com> --- v3: Vladimir's Tested-by arch/arm/kernel/head

[PATCH v3 3/3] ARM: nommu: remove Hivecs configuration is asm

Now that exception based address is handled dynamically for processors with CP15, remove Hivecs configuration in assembly. Signed-off-by: afzal mohammed Tested-by: Vladimir Murzin --- v3: Vladimir's Tested-by arch/arm/kernel/head-nommu.S | 5 - 1 file changed, 5 deletions(-) diff --git

[PATCH v3 1/3] ARM: nommu: dynamic exception base address setting

-off-by: afzal mohammed <afzal.mohd...@gmail.com> Tested-by: Vladimir Murzin <vladimir.mur...@arm.com> --- v3: Vladimir's Tested-by v2: Use existing helpers to detect security extensions Rewrite a CPP step to C for readability arch/arm

[PATCH v3 1/3] ARM: nommu: dynamic exception base address setting

-off-by: afzal mohammed Tested-by: Vladimir Murzin --- v3: Vladimir's Tested-by v2: Use existing helpers to detect security extensions Rewrite a CPP step to C for readability arch/arm/mm/nommu.c | 52 ++-- 1 file changed, 50 insertions(+), 2 delet

[PATCH v3 0/3] ARM: !MMU: v7-A support, dynamic vectors base handling

ad.org/pipermail/linux-arm-kernel/2017-January/481904.html (in -next) [3] "[RFC v2 PATCH 00/23] Allow NOMMU for MULTIPLATFORM", http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/470966.html (git://linux-arm.org/linux-vm.git nommu-rfc-v2) afzal mohammed (3):

[PATCH v3 0/3] ARM: !MMU: v7-A support, dynamic vectors base handling

ad.org/pipermail/linux-arm-kernel/2017-January/481904.html (in -next) [3] "[RFC v2 PATCH 00/23] Allow NOMMU for MULTIPLATFORM", http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/470966.html (git://linux-arm.org/linux-vm.git nommu-rfc-v2) afzal mohammed (3):

Re: [PATCH v2 3/4] ARM: nommu: display vectors base

Hi, On Mon, Jan 30, 2017 at 02:03:26PM +, Russell King - ARM Linux wrote: > On Sun, Jan 22, 2017 at 08:52:12AM +0530, afzal mohammed wrote: > > The exception base address is now dynamically estimated for no-MMU, > > display it. As it is the case, now limit VECTORS_BA

Re: [PATCH v2 3/4] ARM: nommu: display vectors base

Hi, On Mon, Jan 30, 2017 at 02:03:26PM +, Russell King - ARM Linux wrote: > On Sun, Jan 22, 2017 at 08:52:12AM +0530, afzal mohammed wrote: > > The exception base address is now dynamically estimated for no-MMU, > > display it. As it is the case, now limit VECTORS_BA

[PATCH] ARM: vf610m4: defconfig: enable EXT4 filesystem

Enable EXT4_FS to have rootfs in EXT[2-4]. Other changes are result of savedefconfig keeping minimal config (even without enabling EXT4_FS, these would be present). Signed-off-by: afzal mohammed <afzal.mohd...@gmail.com> --- Hi Shawn, i am not sure about the route for this patch, s

[PATCH] ARM: vf610m4: defconfig: enable EXT4 filesystem

Enable EXT4_FS to have rootfs in EXT[2-4]. Other changes are result of savedefconfig keeping minimal config (even without enabling EXT4_FS, these would be present). Signed-off-by: afzal mohammed --- Hi Shawn, i am not sure about the route for this patch, sending it you as the Vybrid

Re: [PATCH 2/4] ARM: nommu: dynamic exception base address setting

Hi, On Fri, Jan 20, 2017 at 09:50:22PM +0530, Afzal Mohammed wrote: > On Thu, Jan 19, 2017 at 01:59:09PM +, Vladimir Murzin wrote: > > You can use > > > > cpuid_feature_extract(CPUID_EXT_PFR1, 4) > > > > and add a comment explaining what we are loo

Re: [PATCH 2/4] ARM: nommu: dynamic exception base address setting

Hi, On Fri, Jan 20, 2017 at 09:50:22PM +0530, Afzal Mohammed wrote: > On Thu, Jan 19, 2017 at 01:59:09PM +, Vladimir Murzin wrote: > > You can use > > > > cpuid_feature_extract(CPUID_EXT_PFR1, 4) > > > > and add a comment explaining what we are loo

Re: [PATCH 1/4] ARM: mmu: decouple VECTORS_BASE from Kconfig

Hi, On Thu, Jan 19, 2017 at 02:24:24PM +, Russell King - ARM Linux wrote: > On Thu, Jan 19, 2017 at 02:07:39AM +0530, afzal mohammed wrote: > > +#define VECTORS_BASE 0x > > This should be UL(0x) This has been taken care in v2. Regards afzal

Re: [PATCH 1/4] ARM: mmu: decouple VECTORS_BASE from Kconfig

Hi, On Thu, Jan 19, 2017 at 02:24:24PM +, Russell King - ARM Linux wrote: > On Thu, Jan 19, 2017 at 02:07:39AM +0530, afzal mohammed wrote: > > +#define VECTORS_BASE 0x > > This should be UL(0x) This has been taken care in v2. Regards afzal

[PATCH v2 4/4] ARM: nommu: remove Hivecs configuration is asm

Now that exception based address is handled dynamically for processors with CP15, remove Hivecs configuration in assembly. Signed-off-by: afzal mohammed <afzal.mohd...@gmail.com> --- arch/arm/kernel/head-nommu.S | 5 - 1 file changed, 5 deletions(-) diff --git a/arch/arm/kernel/head-n

[PATCH v2 4/4] ARM: nommu: remove Hivecs configuration is asm

Now that exception based address is handled dynamically for processors with CP15, remove Hivecs configuration in assembly. Signed-off-by: afzal mohammed --- arch/arm/kernel/head-nommu.S | 5 - 1 file changed, 5 deletions(-) diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head

[PATCH v2 3/4] ARM: nommu: display vectors base

The exception base address is now dynamically estimated for no-MMU, display it. As it is the case, now limit VECTORS_BASE usage to MMU scenario. Signed-off-by: afzal mohammed <afzal.mohd...@gmail.com> --- v2: A change to accomodate bisectability resolution on patch 1/4 arch/arm/inclu

[PATCH v2 3/4] ARM: nommu: display vectors base

The exception base address is now dynamically estimated for no-MMU, display it. As it is the case, now limit VECTORS_BASE usage to MMU scenario. Signed-off-by: afzal mohammed --- v2: A change to accomodate bisectability resolution on patch 1/4 arch/arm/include/asm/memory.h | 4 ++-- arch/arm

[PATCH v2 2/4] ARM: nommu: dynamic exception base address setting

-off-by: afzal mohammed <afzal.mohd...@gmail.com> --- v2: Use existing helpers to detect security extensions Rewrite a CPP step to C for readability arch/arm/mm/nommu.c | 52 ++-- 1 file changed, 50 insertions(+), 2 deletions(-) diff --git a/a

[PATCH v2 2/4] ARM: nommu: dynamic exception base address setting

-off-by: afzal mohammed --- v2: Use existing helpers to detect security extensions Rewrite a CPP step to C for readability arch/arm/mm/nommu.c | 52 ++-- 1 file changed, 50 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm/nommu.c b/arch/ar

[PATCH v2 1/4] ARM: mmu: decouple VECTORS_BASE from Kconfig

ker...@arm.linux.org.uk> Signed-off-by: afzal mohammed <afzal.mohd...@gmail.com> --- v2: Fix bisectability issue on !MMU builds UL suffix on VECTORS_BASE definition arch/arm/include/asm/memory.h | 2 ++ arch/arm/mach-berlin/platsmp.c | 3 ++- arch/arm/mm/dump.c | 5 +++-- arch/a

  1   2   3   4   5   6   7   >