On Thu, Nov 01, 2018 at 07:20:49PM +0800, Wang Yufen wrote:
> From: Yufen Wang
>
> In case panic() and panic() called at the same time on different CPUS.
> For example:
> CPU 0:
> panic()
> __crash_kexec
>machine_crash_shutdown
> crash_smp_send_stop
>machine_kexec
On Mon, Oct 29, 2018 at 04:52:04PM -0700, Florian Fainelli wrote:
> If the architecture implements ARCH_HAS_PHYS_INITRD, make the FDT
> scanning code populate the physical address of the start of the FDT and
> its size.
>
> Signed-off-by: Florian Fainelli
> ---
> arch/arm/mm/init.c | 2 +-
>
On Mon, Oct 29, 2018 at 04:52:04PM -0700, Florian Fainelli wrote:
> If the architecture implements ARCH_HAS_PHYS_INITRD, make the FDT
> scanning code populate the physical address of the start of the FDT and
> its size.
>
> Signed-off-by: Florian Fainelli
> ---
> arch/arm/mm/init.c | 2 +-
>
On Mon, Oct 29, 2018 at 03:54:36PM +, Mark Rutland wrote:
> On Mon, Oct 29, 2018 at 02:20:51PM +, Wiebe, Wladislav (Nokia - DE/Ulm)
> wrote:
> > When running into situations like:
> > "Unhandled fault: synchronous external abort (0x210) at 0xXXX"
> > or
> > "Unhandled prefetch abort:
On Mon, Oct 29, 2018 at 03:54:36PM +, Mark Rutland wrote:
> On Mon, Oct 29, 2018 at 02:20:51PM +, Wiebe, Wladislav (Nokia - DE/Ulm)
> wrote:
> > When running into situations like:
> > "Unhandled fault: synchronous external abort (0x210) at 0xXXX"
> > or
> > "Unhandled prefetch abort:
On Mon, Oct 29, 2018 at 02:20:51PM +, Wiebe, Wladislav (Nokia - DE/Ulm)
wrote:
> When running into situations like:
> "Unhandled fault: synchronous external abort (0x210) at 0xXXX"
> or
> "Unhandled prefetch abort: synchronous external abort (0x210) at 0xXXX"
> it is useful to know the
On Mon, Oct 29, 2018 at 02:20:51PM +, Wiebe, Wladislav (Nokia - DE/Ulm)
wrote:
> When running into situations like:
> "Unhandled fault: synchronous external abort (0x210) at 0xXXX"
> or
> "Unhandled prefetch abort: synchronous external abort (0x210) at 0xXXX"
> it is useful to know the
On Fri, Oct 26, 2018 at 12:00:09AM +0530, Souptick Joarder wrote:
> On Thu, Oct 25, 2018 at 11:40 PM Florian Fainelli
> wrote:
> >
> > Some software such as perf makes unconditional use of the special
> > [vectors] page which is only provided when CONFIG_KUSER_HELPERS is
> > enabled in the
On Fri, Oct 26, 2018 at 12:00:09AM +0530, Souptick Joarder wrote:
> On Thu, Oct 25, 2018 at 11:40 PM Florian Fainelli
> wrote:
> >
> > Some software such as perf makes unconditional use of the special
> > [vectors] page which is only provided when CONFIG_KUSER_HELPERS is
> > enabled in the
On Thu, Oct 25, 2018 at 10:53:12AM -0700, Florian Fainelli wrote:
> Something like this below? It does not have to be an alternative
> solution, I would find it useful for perf to make sure the vectors page
> is present in the virtual address space by having an explicit test. perf
> maintains,
On Thu, Oct 25, 2018 at 10:53:12AM -0700, Florian Fainelli wrote:
> Something like this below? It does not have to be an alternative
> solution, I would find it useful for perf to make sure the vectors page
> is present in the virtual address space by having an explicit test. perf
> maintains,
On Thu, Oct 25, 2018 at 10:19:54AM -0700, Florian Fainelli wrote:
> On 10/24/18 7:10 PM, Andrew Lunn wrote:
> > On Wed, Oct 24, 2018 at 05:09:05PM -0700, Florian Fainelli wrote:
> >> perf on ARM requires CONFIG_KUSER_HELPERS to be turned on to allow some
> >> independance with respect to the ARM
On Thu, Oct 25, 2018 at 10:19:54AM -0700, Florian Fainelli wrote:
> On 10/24/18 7:10 PM, Andrew Lunn wrote:
> > On Wed, Oct 24, 2018 at 05:09:05PM -0700, Florian Fainelli wrote:
> >> perf on ARM requires CONFIG_KUSER_HELPERS to be turned on to allow some
> >> independance with respect to the ARM
On Thu, Oct 25, 2018 at 08:25:04AM -0500, Rob Herring wrote:
> On Wed, Oct 24, 2018 at 7:17 PM Florian Fainelli wrote:
> >
> > ARM64 is the only architecture that requires a re-definition of
> > __early_init_dt_declare_initrd(), absorb its custom implemention in
> > drivers/of/fdt.c.
> >
> >
On Thu, Oct 25, 2018 at 08:25:04AM -0500, Rob Herring wrote:
> On Wed, Oct 24, 2018 at 7:17 PM Florian Fainelli wrote:
> >
> > ARM64 is the only architecture that requires a re-definition of
> > __early_init_dt_declare_initrd(), absorb its custom implemention in
> > drivers/of/fdt.c.
> >
> >
On Thu, Oct 25, 2018 at 09:37:59AM -0300, Rafael David Tinoco wrote:
> Is it okay to propose using only MAX_PHYSMEM_BITS for zsmalloc (like
> it was before commit 02390b87) instead, and make sure *at least* ARM
> 32/64 and x86/x64, for now, have it defined outside sparsemem headers
> as well ?
It
On Thu, Oct 25, 2018 at 09:37:59AM -0300, Rafael David Tinoco wrote:
> Is it okay to propose using only MAX_PHYSMEM_BITS for zsmalloc (like
> it was before commit 02390b87) instead, and make sure *at least* ARM
> 32/64 and x86/x64, for now, have it defined outside sparsemem headers
> as well ?
It
On Wed, Oct 24, 2018 at 10:27:44PM -0300, Rafael David Tinoco wrote:
> On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the
> physical frame number might be so big that zsmalloc obj encoding (to
> location) will break IF architecture does not re-define
> MAX_PHYSMEM_BITS,
On Wed, Oct 24, 2018 at 10:27:44PM -0300, Rafael David Tinoco wrote:
> On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the
> physical frame number might be so big that zsmalloc obj encoding (to
> location) will break IF architecture does not re-define
> MAX_PHYSMEM_BITS,
On Wed, Oct 24, 2018 at 04:20:03PM +0530, shubhrajyoti.da...@gmail.com wrote:
> From: Shubhrajyoti Datta
>
> In some cases we are waiting in a loop. Replace the infinite wait with
> the timeout.
>
> Signed-off-by: Shubhrajyoti Datta
> ---
> drivers/i2c/busses/i2c-cadence.c | 30
On Wed, Oct 24, 2018 at 04:20:03PM +0530, shubhrajyoti.da...@gmail.com wrote:
> From: Shubhrajyoti Datta
>
> In some cases we are waiting in a loop. Replace the infinite wait with
> the timeout.
>
> Signed-off-by: Shubhrajyoti Datta
> ---
> drivers/i2c/busses/i2c-cadence.c | 30
On Wed, Oct 24, 2018 at 07:35:46AM +, Corentin Labbe wrote:
> This patchset adds a new set of functions which are open-coded in lot of
> place.
> Basicly the pattern is always the same, "read, modify a bit, write"
> some driver and the powerpc arch already have thoses pattern them as
>
On Wed, Oct 24, 2018 at 07:35:46AM +, Corentin Labbe wrote:
> This patchset adds a new set of functions which are open-coded in lot of
> place.
> Basicly the pattern is always the same, "read, modify a bit, write"
> some driver and the powerpc arch already have thoses pattern them as
>
On Tue, Oct 23, 2018 at 10:47:05AM +0200, Clément Péron wrote:
> Hi Dinh / Russell,
>
> Could you have a look at these patchs please ?
Nothing to do with me - it's up to the socfpga maintainer and arm-soc
maintainers.
> Thanks,
> Clement
>
> On Tue, 9 Oct 2018 at 13:20, Clément Péron wrote:
>
On Tue, Oct 23, 2018 at 10:47:05AM +0200, Clément Péron wrote:
> Hi Dinh / Russell,
>
> Could you have a look at these patchs please ?
Nothing to do with me - it's up to the socfpga maintainer and arm-soc
maintainers.
> Thanks,
> Clement
>
> On Tue, 9 Oct 2018 at 13:20, Clément Péron wrote:
>
On Thu, Oct 18, 2018 at 02:16:47PM +0800, Teng Fei Fan wrote:
> This patch adds support for cacheinfo on 32bit ARMv8 platform.
> Add support for detecting cpu cache information cpu cache information
> via sysfs for 32bit armv8 platform. And export to sysfs then userspace
> can get from
On Thu, Oct 18, 2018 at 02:16:47PM +0800, Teng Fei Fan wrote:
> This patch adds support for cacheinfo on 32bit ARMv8 platform.
> Add support for detecting cpu cache information cpu cache information
> via sysfs for 32bit armv8 platform. And export to sysfs then userspace
> can get from
On Tue, Oct 16, 2018 at 04:55:00PM +0300, Andy Shevchenko wrote:
> On Tue, Oct 16, 2018 at 3:55 PM Andrzej Hajda wrote:
> > On 16.10.2018 13:29, Andrzej Hajda wrote:
> > > On 16.10.2018 13:01, Andy Shevchenko wrote:
> > >> On Tue, Oct 16, 2018 at 10:22 AM Andrzej Hajda
> > >> wrote:
> > >>>
On Tue, Oct 16, 2018 at 04:55:00PM +0300, Andy Shevchenko wrote:
> On Tue, Oct 16, 2018 at 3:55 PM Andrzej Hajda wrote:
> > On 16.10.2018 13:29, Andrzej Hajda wrote:
> > > On 16.10.2018 13:01, Andy Shevchenko wrote:
> > >> On Tue, Oct 16, 2018 at 10:22 AM Andrzej Hajda
> > >> wrote:
> > >>>
On Wed, Oct 17, 2018 at 11:04:17AM +0200, Arnd Bergmann wrote:
> The constraints were originally added in commit 9a40ac86152c ("ARM:
> 6164/1: Add kto and kfrom to input operands list.") as a gcc-4.5
> workaround. Another workaround for the same problem was added in commit
> 9c695203a7dd
On Wed, Oct 17, 2018 at 11:04:17AM +0200, Arnd Bergmann wrote:
> The constraints were originally added in commit 9a40ac86152c ("ARM:
> 6164/1: Add kto and kfrom to input operands list.") as a gcc-4.5
> workaround. Another workaround for the same problem was added in commit
> 9c695203a7dd
On Tue, Oct 16, 2018 at 10:00:19AM +0200, Linus Walleij wrote:
> On Tue, Oct 16, 2018 at 12:16 AM Stefan Agner wrote:
>
> > When functions incoming parameters are not in input operands list gcc
> > 4.5 does not load the parameters into registers before calling this
> > function but the inline
On Tue, Oct 16, 2018 at 10:00:19AM +0200, Linus Walleij wrote:
> On Tue, Oct 16, 2018 at 12:16 AM Stefan Agner wrote:
>
> > When functions incoming parameters are not in input operands list gcc
> > 4.5 does not load the parameters into registers before calling this
> > function but the inline
On Mon, Oct 15, 2018 at 07:27:43PM -0400, Nicolas Pitre wrote:
> It's hard to see what that commit was actually fixing, but the operands
> usage is wrong as explained already. Maybe the generated code has been
> OK for all those years but that is due to luck rather than correctness.
...
> No
On Mon, Oct 15, 2018 at 07:27:43PM -0400, Nicolas Pitre wrote:
> It's hard to see what that commit was actually fixing, but the operands
> usage is wrong as explained already. Maybe the generated code has been
> OK for all those years but that is due to luck rather than correctness.
...
> No
On Tue, Oct 16, 2018 at 12:52:58AM +0200, Stefan Agner wrote:
> On 16.10.2018 00:46, Russell King - ARM Linux wrote:
> > On Tue, Oct 16, 2018 at 12:39:54AM +0200, Stefan Agner wrote:
> >> On 16.10.2018 00:23, Russell King - ARM Linux wrote:
> >> > On Tue, Oct 16, 20
On Tue, Oct 16, 2018 at 12:52:58AM +0200, Stefan Agner wrote:
> On 16.10.2018 00:46, Russell King - ARM Linux wrote:
> > On Tue, Oct 16, 2018 at 12:39:54AM +0200, Stefan Agner wrote:
> >> On 16.10.2018 00:23, Russell King - ARM Linux wrote:
> >> > On Tue, Oct 16, 20
On Mon, Oct 15, 2018 at 06:54:49PM -0400, Nicolas Pitre wrote:
> On Mon, 15 Oct 2018, Russell King - ARM Linux wrote:
>
> > On Mon, Oct 15, 2018 at 06:35:33PM -0400, Nicolas Pitre wrote:
> > > On Tue, 16 Oct 2018, Stefan Agner wrote:
> > >
> > > > GCC
On Mon, Oct 15, 2018 at 06:54:49PM -0400, Nicolas Pitre wrote:
> On Mon, 15 Oct 2018, Russell King - ARM Linux wrote:
>
> > On Mon, Oct 15, 2018 at 06:35:33PM -0400, Nicolas Pitre wrote:
> > > On Tue, 16 Oct 2018, Stefan Agner wrote:
> > >
> > > > GCC
On Tue, Oct 16, 2018 at 12:39:54AM +0200, Stefan Agner wrote:
> On 16.10.2018 00:23, Russell King - ARM Linux wrote:
> > On Tue, Oct 16, 2018 at 12:16:29AM +0200, Stefan Agner wrote:
> >> When functions incoming parameters are not in input operands list gcc
> >> 4.5 d
On Tue, Oct 16, 2018 at 12:39:54AM +0200, Stefan Agner wrote:
> On 16.10.2018 00:23, Russell King - ARM Linux wrote:
> > On Tue, Oct 16, 2018 at 12:16:29AM +0200, Stefan Agner wrote:
> >> When functions incoming parameters are not in input operands list gcc
> >> 4.5 d
On Mon, Oct 15, 2018 at 06:35:33PM -0400, Nicolas Pitre wrote:
> On Tue, 16 Oct 2018, Stefan Agner wrote:
>
> > GCC documentation says naked functions should only use basic ASM
> > syntax. The extended ASM or mixture of basic ASM and "C" code is
> > not guaranteed. Currently it seems to work
On Mon, Oct 15, 2018 at 06:35:33PM -0400, Nicolas Pitre wrote:
> On Tue, 16 Oct 2018, Stefan Agner wrote:
>
> > GCC documentation says naked functions should only use basic ASM
> > syntax. The extended ASM or mixture of basic ASM and "C" code is
> > not guaranteed. Currently it seems to work
On Tue, Oct 16, 2018 at 12:16:29AM +0200, Stefan Agner wrote:
> When functions incoming parameters are not in input operands list gcc
> 4.5 does not load the parameters into registers before calling this
> function but the inline assembly assumes valid addresses inside this
> function. This breaks
On Tue, Oct 16, 2018 at 12:16:29AM +0200, Stefan Agner wrote:
> When functions incoming parameters are not in input operands list gcc
> 4.5 does not load the parameters into registers before calling this
> function but the inline assembly assumes valid addresses inside this
> function. This breaks
On Fri, Oct 12, 2018 at 11:43:13AM +, Marcel Ziswiler wrote:
> I don't think it is that fictitious as it makes it crystal clear that
> there is something shared with all its pros and cons. E.g. what happens
> if one of them regulators wants to turn off while the other one still
> needs power?
On Fri, Oct 12, 2018 at 11:43:13AM +, Marcel Ziswiler wrote:
> I don't think it is that fictitious as it makes it crystal clear that
> there is something shared with all its pros and cons. E.g. what happens
> if one of them regulators wants to turn off while the other one still
> needs power?
On Fri, Oct 12, 2018 at 11:39:15AM +0100, Jon Hunter wrote:
> We had the same situation for Tegra124 Jetson TK1 but I don't think that
> adding a pseudo intermediate regulator is cleaner. If the GPIO controls
> more than one regulator, I don't see why is it necessary to change the
> DT. There are
On Fri, Oct 12, 2018 at 11:39:15AM +0100, Jon Hunter wrote:
> We had the same situation for Tegra124 Jetson TK1 but I don't think that
> adding a pseudo intermediate regulator is cleaner. If the GPIO controls
> more than one regulator, I don't see why is it necessary to change the
> DT. There are
On Wed, Oct 10, 2018 at 02:04:14PM +0200, Stefan Wahren wrote:
> Hi,
>
> Am 10.10.2018 um 13:19 schrieb Rob Herring:
> > On Wed, Oct 10, 2018 at 6:08 AM Masahiro Yamada
> > wrote:
> >> Hi,
> >>
> >>
> >> I see a bunch of vendor (or SoC) names in
> >> Documentation/device/bindings/arm/
> >>
> >>
On Wed, Oct 10, 2018 at 02:04:14PM +0200, Stefan Wahren wrote:
> Hi,
>
> Am 10.10.2018 um 13:19 schrieb Rob Herring:
> > On Wed, Oct 10, 2018 at 6:08 AM Masahiro Yamada
> > wrote:
> >> Hi,
> >>
> >>
> >> I see a bunch of vendor (or SoC) names in
> >> Documentation/device/bindings/arm/
> >>
> >>
On Wed, Oct 10, 2018 at 08:07:52PM +0900, Masahiro Yamada wrote:
> Hi,
>
>
> I see a bunch of vendor (or SoC) names in
> Documentation/device/bindings/arm/
>
> ./Documentation/devicetree/bindings/arm/altera
> ./Documentation/devicetree/bindings/arm/amlogic
>
On Wed, Oct 10, 2018 at 08:07:52PM +0900, Masahiro Yamada wrote:
> Hi,
>
>
> I see a bunch of vendor (or SoC) names in
> Documentation/device/bindings/arm/
>
> ./Documentation/devicetree/bindings/arm/altera
> ./Documentation/devicetree/bindings/arm/amlogic
>
On Tue, Oct 09, 2018 at 04:58:18PM +0100, Will Deacon wrote:
> On Tue, Oct 09, 2018 at 05:43:59PM +0200, Peter Zijlstra wrote:
> > On Tue, Oct 09, 2018 at 05:39:27PM +0200, Lukasz Luba wrote:
> > > This patch add some warning related to performance drop.
> > > It should be mentioned that this is
On Tue, Oct 09, 2018 at 04:58:18PM +0100, Will Deacon wrote:
> On Tue, Oct 09, 2018 at 05:43:59PM +0200, Peter Zijlstra wrote:
> > On Tue, Oct 09, 2018 at 05:39:27PM +0200, Lukasz Luba wrote:
> > > This patch add some warning related to performance drop.
> > > It should be mentioned that this is
On Fri, Oct 05, 2018 at 10:15:57AM +0530, Manjeet Pawar wrote:
> From: Rohit Thapliyal
>
> During user undefined instruction exception, the arm exception
> handler currently results in application crash through SIGILL.
> The bad instruction can be due to ddr/hardware issue.
> For such cases,
On Fri, Oct 05, 2018 at 10:15:57AM +0530, Manjeet Pawar wrote:
> From: Rohit Thapliyal
>
> During user undefined instruction exception, the arm exception
> handler currently results in application crash through SIGILL.
> The bad instruction can be due to ddr/hardware issue.
> For such cases,
On Fri, Oct 05, 2018 at 10:27:48AM +0200, Nicolas Cavallari wrote:
> On 04/10/2018 18:49, Russell King - ARM Linux wrote:
> > This isn't going to work.
> >
> > For example, sysrq processing (which can happen in IRQ context) calls
> > emergency_restart() for the reboot
On Fri, Oct 05, 2018 at 10:27:48AM +0200, Nicolas Cavallari wrote:
> On 04/10/2018 18:49, Russell King - ARM Linux wrote:
> > This isn't going to work.
> >
> > For example, sysrq processing (which can happen in IRQ context) calls
> > emergency_restart() for the reboot
On Thu, Oct 04, 2018 at 06:23:38PM +0200, Nicolas Cavallari wrote:
> Many users of restart_handlers are sleeping in their callbacks. Some
> are doing infinite loops or calling driver code that may sleep or
> perform operation on slow busses, like i2c.
>
> This is not allowed in an atomic
On Thu, Oct 04, 2018 at 06:23:38PM +0200, Nicolas Cavallari wrote:
> Many users of restart_handlers are sleeping in their callbacks. Some
> are doing infinite loops or calling driver code that may sleep or
> perform operation on slow busses, like i2c.
>
> This is not allowed in an atomic
On Thu, Oct 04, 2018 at 05:45:13PM +0530, Souptick Joarder wrote:
> On Thu, Oct 4, 2018 at 3:45 AM Russell King - ARM Linux
> wrote:
> >
> > On Wed, Oct 03, 2018 at 01:00:03PM -0700, Matthew Wilcox wrote:
> > > On Thu, Oct 04, 2018 at 12:28:54AM +0
On Thu, Oct 04, 2018 at 05:45:13PM +0530, Souptick Joarder wrote:
> On Thu, Oct 4, 2018 at 3:45 AM Russell King - ARM Linux
> wrote:
> >
> > On Wed, Oct 03, 2018 at 01:00:03PM -0700, Matthew Wilcox wrote:
> > > On Thu, Oct 04, 2018 at 12:28:54AM +0
On Thu, Oct 04, 2018 at 10:54:15AM +0200, Clément Péron wrote:
> From: Dinh Nguyen
>
> Turn on these ARM and PL310 errata for SoCFPGA:
>
> ARM_ERRATA_754322
> ARM_ERRATA_764369
> ARM_ERRATA_775420
>
> PL310_ERRATA_588369
> PL310_ERRATA_727915
> PL310_ERRATA_753970
> PL310_ERRATA_769419
>
>
On Thu, Oct 04, 2018 at 10:54:15AM +0200, Clément Péron wrote:
> From: Dinh Nguyen
>
> Turn on these ARM and PL310 errata for SoCFPGA:
>
> ARM_ERRATA_754322
> ARM_ERRATA_764369
> ARM_ERRATA_775420
>
> PL310_ERRATA_588369
> PL310_ERRATA_727915
> PL310_ERRATA_753970
> PL310_ERRATA_769419
>
>
On Mon, Oct 01, 2018 at 01:44:52PM -0700, Mark Salyzyn wrote:
> Despite the gain of 0.4% for screen-on battery life, where Android has a mix
> of 64 and 32 bit applications, thus still relevant _today_ on 64 bit
> architectures (providing vDSO32 for 32-bit applications).
I don't think the issue
On Mon, Oct 01, 2018 at 01:44:52PM -0700, Mark Salyzyn wrote:
> Despite the gain of 0.4% for screen-on battery life, where Android has a mix
> of 64 and 32 bit applications, thus still relevant _today_ on 64 bit
> architectures (providing vDSO32 for 32-bit applications).
I don't think the issue
On Mon, Oct 01, 2018 at 08:10:26PM +0200, Ard Biesheuvel wrote:
> On 1 October 2018 at 19:56, Russell King - ARM Linux
> wrote:
> > On Sun, Sep 30, 2018 at 04:49:04AM +0200, Jason A. Donenfeld wrote:
> >> Per the discussion about half-way down in [1], the kernel doesn't
On Mon, Oct 01, 2018 at 08:10:26PM +0200, Ard Biesheuvel wrote:
> On 1 October 2018 at 19:56, Russell King - ARM Linux
> wrote:
> > On Sun, Sep 30, 2018 at 04:49:04AM +0200, Jason A. Donenfeld wrote:
> >> Per the discussion about half-way down in [1], the kernel doesn't
On Sun, Sep 30, 2018 at 04:49:04AM +0200, Jason A. Donenfeld wrote:
> Per the discussion about half-way down in [1], the kernel doesn't
> actually support the ARMv3 ISA, but selects it for some ARMv4 ISA
> hardware that benefits from ARMv3 code generation.
The issue is to do with the half-word
On Sun, Sep 30, 2018 at 04:49:04AM +0200, Jason A. Donenfeld wrote:
> Per the discussion about half-way down in [1], the kernel doesn't
> actually support the ARMv3 ISA, but selects it for some ARMv4 ISA
> hardware that benefits from ARMv3 code generation.
The issue is to do with the half-word
On Sun, Sep 30, 2018 at 04:48:20PM -0700, Joe Perches wrote:
> On Mon, 2018-10-01 at 00:22 +0200, Stefan Agner wrote:
> > The kernel passes the ArmV6K architecture to the compiler when
> > using the multi platform selection and enabling ARMv6. Clang
> > older than version 8.0 emit assembly with an
On Sun, Sep 30, 2018 at 04:48:20PM -0700, Joe Perches wrote:
> On Mon, 2018-10-01 at 00:22 +0200, Stefan Agner wrote:
> > The kernel passes the ArmV6K architecture to the compiler when
> > using the multi platform selection and enabling ARMv6. Clang
> > older than version 8.0 emit assembly with an
On Sat, Sep 29, 2018 at 01:20:36PM +0800, Jisheng Zhang wrote:
> Hi,
>
> Recently I found I could trigger sleep in atomic bug on berlin after commit
> d76c74387e1c ("serial: 8250_dw: Fix runtime PM handling"). The path looks
> like:
>
> dw8250_probe => serial850_register_8250_port =>
On Sat, Sep 29, 2018 at 01:20:36PM +0800, Jisheng Zhang wrote:
> Hi,
>
> Recently I found I could trigger sleep in atomic bug on berlin after commit
> d76c74387e1c ("serial: 8250_dw: Fix runtime PM handling"). The path looks
> like:
>
> dw8250_probe => serial850_register_8250_port =>
On Mon, Sep 24, 2018 at 12:26:14PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 24 Sep 2018 11:12:13 +0100, Russell King - ARM Linux wrote:
>
> > > Thanks for the testing. I'll wait for Russell to say if he is happy
> > > (or not) with the addition of
On Mon, Sep 24, 2018 at 12:26:14PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 24 Sep 2018 11:12:13 +0100, Russell King - ARM Linux wrote:
>
> > > Thanks for the testing. I'll wait for Russell to say if he is happy
> > > (or not) with the addition of
On Thu, Sep 13, 2018 at 10:42:41AM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Thu, 13 Sep 2018 10:20:45 +0200, Jan Kundrát wrote:
> > On čtvrtek 13. září 2018 9:45:15 CEST, Thomas Petazzoni wrote:
> > > What about something like the below. I tested it, including the error
> > > case by
On Thu, Sep 13, 2018 at 10:42:41AM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Thu, 13 Sep 2018 10:20:45 +0200, Jan Kundrát wrote:
> > On čtvrtek 13. září 2018 9:45:15 CEST, Thomas Petazzoni wrote:
> > > What about something like the below. I tested it, including the error
> > > case by
On Thu, Sep 20, 2018 at 10:13:57PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> For years arm has been using serial.h from asm-generic which sets
> BASE_BAUD value to the (1843200 / 16). This is incorrect as:
> 1) This value obviously isn't correct for all devices
> 2) There are no
On Thu, Sep 20, 2018 at 10:13:57PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> For years arm has been using serial.h from asm-generic which sets
> BASE_BAUD value to the (1843200 / 16). This is incorrect as:
> 1) This value obviously isn't correct for all devices
> 2) There are no
On Wed, Sep 12, 2018 at 09:49:41PM +0300, Baruch Siach wrote:
> I reproduced the same Oops on Clearfog Base without any taint:
>
> [1.476401] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
...
> [1.855954] Code: e2844004 e5972000 e352 0aee (e7f001f2)
That is a
On Wed, Sep 12, 2018 at 09:49:41PM +0300, Baruch Siach wrote:
> I reproduced the same Oops on Clearfog Base without any taint:
>
> [1.476401] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
...
> [1.855954] Code: e2844004 e5972000 e352 0aee (e7f001f2)
That is a
On Mon, Aug 27, 2018 at 01:03:42PM -0700, Florian Fainelli wrote:
> Enable the SFP connected to port 5 of the switch and wire up all GPIOs
> to the SFP cage. Because of a hardware limitation of the i2c controller
> on the iProc SoCs which prevents large i2c (> 256 bytes) transactions to
> work, we
On Mon, Aug 27, 2018 at 01:03:42PM -0700, Florian Fainelli wrote:
> Enable the SFP connected to port 5 of the switch and wire up all GPIOs
> to the SFP cage. Because of a hardware limitation of the i2c controller
> on the iProc SoCs which prevents large i2c (> 256 bytes) transactions to
> work, we
On Sat, Aug 11, 2018 at 12:31:27PM +0200, Stefan Agner wrote:
> ARM stack unwinding is upstream since 2009 and has been proven
> working well. At this time it is the preferred stack unwinding
> support since it also supports Thumb 2. Do not scare people
> and drop the EXPERIMENTAL mark.
Actually,
On Sat, Aug 11, 2018 at 12:31:27PM +0200, Stefan Agner wrote:
> ARM stack unwinding is upstream since 2009 and has been proven
> working well. At this time it is the preferred stack unwinding
> support since it also supports Thumb 2. Do not scare people
> and drop the EXPERIMENTAL mark.
Actually,
On Wed, Aug 01, 2018 at 10:07:12PM +0200, Andrew Lunn wrote:
> You might want to consider adding clk_optional_get() and
> devm_clk_optional_get().
I think there's attempts to add such APIs but I don't think it's
trivial - it seems to require a _lot_ of discussion.
I think part of that is because
On Wed, Aug 01, 2018 at 10:07:12PM +0200, Andrew Lunn wrote:
> You might want to consider adding clk_optional_get() and
> devm_clk_optional_get().
I think there's attempts to add such APIs but I don't think it's
trivial - it seems to require a _lot_ of discussion.
I think part of that is because
On Tue, Jul 31, 2018 at 04:01:27PM -0400, Alex Bounine wrote:
> On 2018-07-31 02:18 PM, Russell King - ARM Linux wrote:
> >On Tue, Jul 31, 2018 at 01:59:27PM -0400, Alex Bounine wrote:
> >>On 2018-07-31 11:52 AM, Russell King - ARM Linux wrote:
> >>>On Tue, Jul 31,
On Tue, Jul 31, 2018 at 04:01:27PM -0400, Alex Bounine wrote:
> On 2018-07-31 02:18 PM, Russell King - ARM Linux wrote:
> >On Tue, Jul 31, 2018 at 01:59:27PM -0400, Alex Bounine wrote:
> >>On 2018-07-31 11:52 AM, Russell King - ARM Linux wrote:
> >>>On Tue, Jul 31,
On Tue, Jul 31, 2018 at 01:59:27PM -0400, Alex Bounine wrote:
> On 2018-07-31 11:52 AM, Russell King - ARM Linux wrote:
> >On Tue, Jul 31, 2018 at 08:54:14AM -0400, Alex Bounine wrote:
> >>On 2018-07-31 04:41 AM, Will Deacon wrote:
> >>>On Mon, Jul 30, 2018 at 06:50:
On Tue, Jul 31, 2018 at 01:59:27PM -0400, Alex Bounine wrote:
> On 2018-07-31 11:52 AM, Russell King - ARM Linux wrote:
> >On Tue, Jul 31, 2018 at 08:54:14AM -0400, Alex Bounine wrote:
> >>On 2018-07-31 04:41 AM, Will Deacon wrote:
> >>>On Mon, Jul 30, 2018 at 06:50:
On Tue, Jul 31, 2018 at 08:54:14AM -0400, Alex Bounine wrote:
> On 2018-07-31 04:41 AM, Will Deacon wrote:
> >On Mon, Jul 30, 2018 at 06:50:34PM -0400, Alexei Colin wrote:
> >>Platforms with a PCI bus will be offered the RapidIO menu since they may
> >>be want support for a RapidIO PCI device.
On Tue, Jul 31, 2018 at 08:54:14AM -0400, Alex Bounine wrote:
> On 2018-07-31 04:41 AM, Will Deacon wrote:
> >On Mon, Jul 30, 2018 at 06:50:34PM -0400, Alexei Colin wrote:
> >>Platforms with a PCI bus will be offered the RapidIO menu since they may
> >>be want support for a RapidIO PCI device.
On Tue, Jul 31, 2018 at 08:43:02AM -0400, Alex Bounine wrote:
> On 2018-07-31 08:04 AM, Christoph Hellwig wrote:
> >On Mon, Jul 30, 2018 at 06:50:33PM -0400, Alexei Colin wrote:
> >>diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >>index afe350e5e3d9..602a61324890 100644
> >>---
On Tue, Jul 31, 2018 at 08:43:02AM -0400, Alex Bounine wrote:
> On 2018-07-31 08:04 AM, Christoph Hellwig wrote:
> >On Mon, Jul 30, 2018 at 06:50:33PM -0400, Alexei Colin wrote:
> >>diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >>index afe350e5e3d9..602a61324890 100644
> >>---
On Tue, Jul 31, 2018 at 12:50:21AM +0200, Thomas Gleixner wrote:
> On Mon, 30 Jul 2018, Bjorn Helgaas wrote:
>
> > [+cc maintainers of possibly erroneous callers of request_threaded_irq()]
> >
> > On Mon, Jul 30, 2018 at 04:30:28PM -0500, Bjorn Helgaas wrote:
> > > [+cc Thomas, Christoph, LKML]
On Tue, Jul 31, 2018 at 12:50:21AM +0200, Thomas Gleixner wrote:
> On Mon, 30 Jul 2018, Bjorn Helgaas wrote:
>
> > [+cc maintainers of possibly erroneous callers of request_threaded_irq()]
> >
> > On Mon, Jul 30, 2018 at 04:30:28PM -0500, Bjorn Helgaas wrote:
> > > [+cc Thomas, Christoph, LKML]
On Wed, Jul 25, 2018 at 11:06:28PM -0700, bgosw...@codeaurora.org wrote:
> From: Banajit Goswami
>
> The devres group opened for a master is left open-ended (without
> devres_group_close) even after bind() is complete. Similarly, while
> releasing the devres resources for master, the most
901 - 1000 of 8578 matches
Mail list logo
