* Re: [PATCH 2/8] soc: ti: add initial PRM driver with reset control support
From: Tero Kristo @ 2019-08-23 11:27 UTC (permalink / raw)
To: Philipp Zabel, Suman Anna, Keerthy, ssantosh, linux-arm-kernel,
linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <1566550205.3023.4.camel@pengutronix.de>
On 23.8.2019 11.50, Philipp Zabel wrote:
> On Wed, 2019-08-21 at 21:15 +0300, Tero Kristo wrote:
>> On 21.8.2019 18.45, Suman Anna wrote:
>>> On 8/21/19 10:10 AM, Philipp Zabel wrote:
> [...]
>>>> In general, assuming the device tree contains no errors, this should not
>>>> matter much, but I think it is nice if the reset driver, even with a
>>>> misconfigured device tree, can't write into arbitrary bit fields.
>>>
>>> Tero,
>>> Can you add a check for this if possible?
>>
>> Well, I can enforce the usage of reset bit mapping, which I have already
>> implemented for some SoCs like am33xx. If the specific ID is not found,
>> I can bail out. So, basically in this example requesting reset at index
>> 3 would succeed, but it would fail for any other ID; this would be
>> direct HW bit mapping.
>
> That should be fine.
Ok, I am re-working it like this locally right now.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Regression in 5.3-rc1 and later
From: Russell King - ARM Linux admin @ 2019-08-23 11:17 UTC (permalink / raw)
To: Will Deacon, tglx
Cc: linux-arch, shuah, daniel.lezcano, catalin.marinas, arnd, salyzyn,
huw, andre.przywara, Chris Clayton, will.deacon, linux-mips, ralf,
LKML, paul.burton, linux-kselftest, linux, sthotton, 0x7f454c46,
vincenzo.frascino, pcc, linux-arm-kernel
In-Reply-To: <20190823104050.o6golaa4fmdd7np5@willie-the-truck>
On Fri, Aug 23, 2019 at 11:40:50AM +0100, Will Deacon wrote:
> On Fri, Aug 23, 2019 at 11:36:54AM +0100, Russell King - ARM Linux admin wrote:
> > To everyone on the long Cc list...
> >
> > What's happening with this? I was about to merge the patches for 32-bit
> > ARM, which I don't want to do if doing so will cause this regression on
> > 32-bit ARM as well.
>
> tglx fixed it:
>
> https://lkml.kernel.org/r/alpine.DEB.2.21.1908221257580.1983@nanos.tec.linutronix.de
>
> which I assume is getting routed as a fix via -tip.
Right, so Chris reported the issue to everyone involved. Tglx's
reply severely trimmed the Cc list so folk like me had no idea what
was going on, removing even the mailing lists. On the face of it,
it looks like an intentional attempt to cut people out of the loop
who really should've been kept in the loop. Yea, that's just great.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] drm/mediatek: fix implicit function declaration
From: Anders Roxell @ 2019-08-23 11:07 UTC (permalink / raw)
To: ck.hu, p.zabel, airlied, daniel, matthias.bgg
Cc: Anders Roxell, linux-mediatek, linux-arm-kernel, dri-devel,
linux-kernel
When building mtk_drm_drv.o the following build error is seen:
../drivers/gpu/drm/mediatek/mtk_drm_drv.c: In function ‘mtk_drm_kms_init’:
../drivers/gpu/drm/mediatek/mtk_drm_drv.c:291:8: error: implicit declaration of
function ‘dma_set_max_seg_size’; did you mean ‘drm_rect_adjust_size’? [-Werror=implicit-function-declaration]
ret = dma_set_max_seg_size(dma_dev, (unsigned int)DMA_BIT_MASK(32));
^~~~~~~~~~~~~~~~~~~~
drm_rect_adjust_size
../drivers/gpu/drm/mediatek/mtk_drm_drv.c:291:52: error: implicit declaration of
function ‘DMA_BIT_MASK’; did you mean ‘BIT_MASK’? [-Werror=implicit-function-declaration]
ret = dma_set_max_seg_size(dma_dev, (unsigned int)DMA_BIT_MASK(32));
^~~~~~~~~~~~
BIT_MASK
Rework to add a missing include file 'linux/dma-mapping.h', because that
is the (only) header file containing that declaration.
Fixes: 070955558e82 ("drm/mediatek: set DMA max segment size")
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 54536176bcbb..352b81a7a670 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -10,6 +10,7 @@
#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/pm_runtime.h>
+#include <linux/dma-mapping.h>
#include <drm/drm_atomic.h>
#include <drm/drm_atomic_helper.h>
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: Regression in 5.3-rc1 and later
From: Russell King - ARM Linux admin @ 2019-08-23 10:51 UTC (permalink / raw)
To: Vincenzo Frascino
Cc: linux-arch, daniel.lezcano, linux-mips, linux-kselftest, arnd,
huw, andre.przywara, Chris Clayton, will.deacon, LKML, ralf,
salyzyn, paul.burton, linux, 0x7f454c46, catalin.marinas, pcc,
tglx, sthotton, shuah, linux-arm-kernel
In-Reply-To: <8ab59d01-348e-9ac1-2944-5e98acd9b1f8@arm.com>
On Fri, Aug 23, 2019 at 11:43:32AM +0100, Vincenzo Frascino wrote:
> Hi Russell,
>
> On 8/23/19 11:36 AM, Russell King - ARM Linux admin wrote:
> > Hi,
> >
> > To everyone on the long Cc list...
> >
> > What's happening with this? I was about to merge the patches for 32-bit
> > ARM, which I don't want to do if doing so will cause this regression on
> > 32-bit ARM as well.
> >
>
> The regression is sorted as of yesterday, a new patch is going through tip:
> timers/urgent and will be part of the next -rc.
>
> If you want to merge them there should be nothing blocking.
I don't have access to the tip tree.
I'll wait a kernel release cycle instead.
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
From: Russell King - ARM Linux admin @ 2019-08-23 10:50 UTC (permalink / raw)
To: Chris Packham
Cc: mark.rutland, devicetree, jlu, linux-edac, linux-kernel, robh+dt,
james.morse, Gregory CLEMENT, bp, mchehab, linux-arm-kernel,
patches
In-Reply-To: <20190823104621.GY13294@shell.armlinux.org.uk>
On Fri, Aug 23, 2019 at 11:46:21AM +0100, Russell King - ARM Linux admin wrote:
> On Fri, Jul 12, 2019 at 03:48:57PM +1200, Chris Packham wrote:
> > From: Jan Luebbe <jlu@pengutronix.de>
> >
> > The macro name is too generic, so add a AURORA_ prefix.
> >
> > Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
> > Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> > ---
> > arch/arm/include/asm/hardware/cache-aurora-l2.h | 2 +-
>
> I can't apply this series - this file does not exist in my tree, and
> from what git tells me, it never has existed. Maybe it's in someone
> elses tree?
I think the file is in my tree, just as arch/arm/mm/cache-aurora-l2.h
which is where it has been since it was originally submitted in 2012.
>
> > arch/arm/mm/cache-l2x0.c | 4 ++--
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/hardware/cache-aurora-l2.h b/arch/arm/include/asm/hardware/cache-aurora-l2.h
> > index c86124769831..dc5c479ec4c3 100644
> > --- a/arch/arm/include/asm/hardware/cache-aurora-l2.h
> > +++ b/arch/arm/include/asm/hardware/cache-aurora-l2.h
> > @@ -41,7 +41,7 @@
> > #define AURORA_ACR_FORCE_WRITE_THRO_POLICY \
> > (2 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
> >
> > -#define MAX_RANGE_SIZE 1024
> > +#define AURORA_MAX_RANGE_SIZE 1024
> >
> > #define AURORA_WAY_SIZE_SHIFT 2
> >
> > diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> > index 428d08718107..83b733a1f1e6 100644
> > --- a/arch/arm/mm/cache-l2x0.c
> > +++ b/arch/arm/mm/cache-l2x0.c
> > @@ -1352,8 +1352,8 @@ static unsigned long aurora_range_end(unsigned long start, unsigned long end)
> > * since cache range operations stall the CPU pipeline
> > * until completion.
> > */
> > - if (end > start + MAX_RANGE_SIZE)
> > - end = start + MAX_RANGE_SIZE;
> > + if (end > start + AURORA_MAX_RANGE_SIZE)
> > + end = start + AURORA_MAX_RANGE_SIZE;
> >
> > /*
> > * Cache range operations can't straddle a page boundary.
> > --
> > 2.22.0
> >
> >
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
From: Russell King - ARM Linux admin @ 2019-08-23 10:46 UTC (permalink / raw)
To: Chris Packham
Cc: mark.rutland, devicetree, jlu, linux-edac, linux-kernel, robh+dt,
james.morse, Gregory CLEMENT, bp, mchehab, linux-arm-kernel,
patches
In-Reply-To: <20190712034904.5747-2-chris.packham@alliedtelesis.co.nz>
On Fri, Jul 12, 2019 at 03:48:57PM +1200, Chris Packham wrote:
> From: Jan Luebbe <jlu@pengutronix.de>
>
> The macro name is too generic, so add a AURORA_ prefix.
>
> Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> arch/arm/include/asm/hardware/cache-aurora-l2.h | 2 +-
I can't apply this series - this file does not exist in my tree, and
from what git tells me, it never has existed. Maybe it's in someone
elses tree?
> arch/arm/mm/cache-l2x0.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/include/asm/hardware/cache-aurora-l2.h b/arch/arm/include/asm/hardware/cache-aurora-l2.h
> index c86124769831..dc5c479ec4c3 100644
> --- a/arch/arm/include/asm/hardware/cache-aurora-l2.h
> +++ b/arch/arm/include/asm/hardware/cache-aurora-l2.h
> @@ -41,7 +41,7 @@
> #define AURORA_ACR_FORCE_WRITE_THRO_POLICY \
> (2 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
>
> -#define MAX_RANGE_SIZE 1024
> +#define AURORA_MAX_RANGE_SIZE 1024
>
> #define AURORA_WAY_SIZE_SHIFT 2
>
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index 428d08718107..83b733a1f1e6 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -1352,8 +1352,8 @@ static unsigned long aurora_range_end(unsigned long start, unsigned long end)
> * since cache range operations stall the CPU pipeline
> * until completion.
> */
> - if (end > start + MAX_RANGE_SIZE)
> - end = start + MAX_RANGE_SIZE;
> + if (end > start + AURORA_MAX_RANGE_SIZE)
> + end = start + AURORA_MAX_RANGE_SIZE;
>
> /*
> * Cache range operations can't straddle a page boundary.
> --
> 2.22.0
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Regression in 5.3-rc1 and later
From: Vincenzo Frascino @ 2019-08-23 10:43 UTC (permalink / raw)
To: Russell King - ARM Linux admin, Chris Clayton
Cc: linux-arch, linux-mips, linux-kselftest, arnd, huw,
andre.przywara, daniel.lezcano, will.deacon, LKML, ralf, salyzyn,
paul.burton, linux, 0x7f454c46, catalin.marinas, pcc, tglx,
sthotton, shuah, linux-arm-kernel
In-Reply-To: <20190823103654.GX13294@shell.armlinux.org.uk>
Hi Russell,
On 8/23/19 11:36 AM, Russell King - ARM Linux admin wrote:
> Hi,
>
> To everyone on the long Cc list...
>
> What's happening with this? I was about to merge the patches for 32-bit
> ARM, which I don't want to do if doing so will cause this regression on
> 32-bit ARM as well.
>
The regression is sorted as of yesterday, a new patch is going through tip:
timers/urgent and will be part of the next -rc.
If you want to merge them there should be nothing blocking.
> Thanks.
>
> On Thu, Aug 22, 2019 at 07:57:59AM +0100, Chris Clayton wrote:
>> Hi everyone,
>>
>> Firstly, apologies to anyone on the long cc list that turns out not to be particularly interested in the following, but
>> you were all marked as cc'd in the commit message below.
>>
>> I've found a problem that isn't present in 5.2 series or 4.19 series kernels, and seems to have arrived in 5.3-rc1. The
>> problem is that if I suspend (to ram) my laptop, on resume 14 minutes or more after suspending, I have no networking
>> functionality. If I resume the laptop after 13 minutes or less, networking works fine. I haven't tried to get finer
>> grained timings between 13 and 14 minutes, but can do if it would help.
>>
>> ifconfig shows that wlan0 is still up and still has its assigned ip address but, for instance, a ping of any other
>> device on my network, fails as does pinging, say, kernel.org. I've tried "downing" the network with (/sbin/ifdown) and
>> unloading the iwlmvm module and then reloading the module and "upping" (/sbin/ifup) the network, but my network is still
>> unusable. I should add that the problem also manifests if I hibernate the laptop, although my testing of this has been
>> minimal. I can do more if required.
>>
>> As I say, the problem first appears in 5.3-rc1, so I've bisected between 5.2.0 and 5.3-rc1 and that concluded with:
>>
>> [chris:~/kernel/linux]$ git bisect good
>> 7ac8707479886c75f353bfb6a8273f423cfccb23 is the first bad commit
>> commit 7ac8707479886c75f353bfb6a8273f423cfccb23
>> Author: Vincenzo Frascino <vincenzo.frascino@arm.com>
>> Date: Fri Jun 21 10:52:49 2019 +0100
>>
>> x86/vdso: Switch to generic vDSO implementation
>>
>> The x86 vDSO library requires some adaptations to take advantage of the
>> newly introduced generic vDSO library.
>>
>> Introduce the following changes:
>> - Modification of vdso.c to be compliant with the common vdso datapage
>> - Use of lib/vdso for gettimeofday
>>
>> [ tglx: Massaged changelog and cleaned up the function signature formatting ]
>>
>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
>> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>> Cc: linux-arch@vger.kernel.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-mips@vger.kernel.org
>> Cc: linux-kselftest@vger.kernel.org
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Cc: Russell King <linux@armlinux.org.uk>
>> Cc: Ralf Baechle <ralf@linux-mips.org>
>> Cc: Paul Burton <paul.burton@mips.com>
>> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
>> Cc: Mark Salyzyn <salyzyn@android.com>
>> Cc: Peter Collingbourne <pcc@google.com>
>> Cc: Shuah Khan <shuah@kernel.org>
>> Cc: Dmitry Safonov <0x7f454c46@gmail.com>
>> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
>> Cc: Huw Davies <huw@codeweavers.com>
>> Cc: Shijith Thotton <sthotton@marvell.com>
>> Cc: Andre Przywara <andre.przywara@arm.com>
>> Link: https://lkml.kernel.org/r/20190621095252.32307-23-vincenzo.frascino@arm.com
>>
>> arch/x86/Kconfig | 3 +
>> arch/x86/entry/vdso/Makefile | 9 ++
>> arch/x86/entry/vdso/vclock_gettime.c | 245 ++++---------------------------
>> arch/x86/entry/vdso/vdsox32.lds.S | 1 +
>> arch/x86/entry/vsyscall/Makefile | 2 -
>> arch/x86/entry/vsyscall/vsyscall_gtod.c | 83 -----------
>> arch/x86/include/asm/pvclock.h | 2 +-
>> arch/x86/include/asm/vdso/gettimeofday.h | 191 ++++++++++++++++++++++++
>> arch/x86/include/asm/vdso/vsyscall.h | 44 ++++++
>> arch/x86/include/asm/vgtod.h | 75 +---------
>> arch/x86/include/asm/vvar.h | 7 +-
>> arch/x86/kernel/pvclock.c | 1 +
>> 12 files changed, 284 insertions(+), 379 deletions(-)
>> delete mode 100644 arch/x86/entry/vsyscall/vsyscall_gtod.c
>> create mode 100644 arch/x86/include/asm/vdso/gettimeofday.h
>> create mode 100644 arch/x86/include/asm/vdso/vsyscall.h
>>
>> To confirm my bisection was correct, I did a git checkout of 7ac8707479886c75f353bfb6a8273f423cfccb2. As expected, the
>> kernel exhibited the problem I've described. However, a kernel built at the immediately preceding (parent?) commit
>> (bfe801ebe84f42b4666d3f0adde90f504d56e35b) has a working network after a (>= 14minute) suspend/resume cycle.
>>
>> As the module name implies, I'm using wireless networking. The hardware is detected as "Intel(R) Wireless-AC 9260
>> 160MHz, REV=0x324" by iwlwifi.
>>
>> I'm more than happy to provide additional diagnostics (but may need a little hand-holding) and to apply diagnostic or
>> fix patches, but please cc me on any reply as I'm not subscribed to any of the kernel-related mailing lists.
>>
>> Chris
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
--
Regards,
Vincenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Regression in 5.3-rc1 and later
From: Will Deacon @ 2019-08-23 10:40 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: linux, catalin.marinas, will.deacon, LKML, linux-kselftest,
vincenzo.frascino, shuah, linux-arch, daniel.lezcano, arnd,
andre.przywara, Chris Clayton, 0x7f454c46, tglx, pcc,
linux-arm-kernel, huw, linux-mips, ralf, salyzyn, paul.burton,
sthotton
In-Reply-To: <20190823103654.GX13294@shell.armlinux.org.uk>
On Fri, Aug 23, 2019 at 11:36:54AM +0100, Russell King - ARM Linux admin wrote:
> To everyone on the long Cc list...
>
> What's happening with this? I was about to merge the patches for 32-bit
> ARM, which I don't want to do if doing so will cause this regression on
> 32-bit ARM as well.
tglx fixed it:
https://lkml.kernel.org/r/alpine.DEB.2.21.1908221257580.1983@nanos.tec.linutronix.de
which I assume is getting routed as a fix via -tip.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Regression in 5.3-rc1 and later
From: Russell King - ARM Linux admin @ 2019-08-23 10:36 UTC (permalink / raw)
To: Chris Clayton
Cc: linux-arch, vincenzo.frascino, linux-mips, linux-kselftest, arnd,
huw, andre.przywara, daniel.lezcano, will.deacon, LKML, ralf,
salyzyn, paul.burton, linux, 0x7f454c46, catalin.marinas, pcc,
tglx, sthotton, shuah, linux-arm-kernel
In-Reply-To: <faaa3843-09a6-1a21-3448-072eeed1ea00@googlemail.com>
Hi,
To everyone on the long Cc list...
What's happening with this? I was about to merge the patches for 32-bit
ARM, which I don't want to do if doing so will cause this regression on
32-bit ARM as well.
Thanks.
On Thu, Aug 22, 2019 at 07:57:59AM +0100, Chris Clayton wrote:
> Hi everyone,
>
> Firstly, apologies to anyone on the long cc list that turns out not to be particularly interested in the following, but
> you were all marked as cc'd in the commit message below.
>
> I've found a problem that isn't present in 5.2 series or 4.19 series kernels, and seems to have arrived in 5.3-rc1. The
> problem is that if I suspend (to ram) my laptop, on resume 14 minutes or more after suspending, I have no networking
> functionality. If I resume the laptop after 13 minutes or less, networking works fine. I haven't tried to get finer
> grained timings between 13 and 14 minutes, but can do if it would help.
>
> ifconfig shows that wlan0 is still up and still has its assigned ip address but, for instance, a ping of any other
> device on my network, fails as does pinging, say, kernel.org. I've tried "downing" the network with (/sbin/ifdown) and
> unloading the iwlmvm module and then reloading the module and "upping" (/sbin/ifup) the network, but my network is still
> unusable. I should add that the problem also manifests if I hibernate the laptop, although my testing of this has been
> minimal. I can do more if required.
>
> As I say, the problem first appears in 5.3-rc1, so I've bisected between 5.2.0 and 5.3-rc1 and that concluded with:
>
> [chris:~/kernel/linux]$ git bisect good
> 7ac8707479886c75f353bfb6a8273f423cfccb23 is the first bad commit
> commit 7ac8707479886c75f353bfb6a8273f423cfccb23
> Author: Vincenzo Frascino <vincenzo.frascino@arm.com>
> Date: Fri Jun 21 10:52:49 2019 +0100
>
> x86/vdso: Switch to generic vDSO implementation
>
> The x86 vDSO library requires some adaptations to take advantage of the
> newly introduced generic vDSO library.
>
> Introduce the following changes:
> - Modification of vdso.c to be compliant with the common vdso datapage
> - Use of lib/vdso for gettimeofday
>
> [ tglx: Massaged changelog and cleaned up the function signature formatting ]
>
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: linux-arch@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-mips@vger.kernel.org
> Cc: linux-kselftest@vger.kernel.org
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Paul Burton <paul.burton@mips.com>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Cc: Mark Salyzyn <salyzyn@android.com>
> Cc: Peter Collingbourne <pcc@google.com>
> Cc: Shuah Khan <shuah@kernel.org>
> Cc: Dmitry Safonov <0x7f454c46@gmail.com>
> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> Cc: Huw Davies <huw@codeweavers.com>
> Cc: Shijith Thotton <sthotton@marvell.com>
> Cc: Andre Przywara <andre.przywara@arm.com>
> Link: https://lkml.kernel.org/r/20190621095252.32307-23-vincenzo.frascino@arm.com
>
> arch/x86/Kconfig | 3 +
> arch/x86/entry/vdso/Makefile | 9 ++
> arch/x86/entry/vdso/vclock_gettime.c | 245 ++++---------------------------
> arch/x86/entry/vdso/vdsox32.lds.S | 1 +
> arch/x86/entry/vsyscall/Makefile | 2 -
> arch/x86/entry/vsyscall/vsyscall_gtod.c | 83 -----------
> arch/x86/include/asm/pvclock.h | 2 +-
> arch/x86/include/asm/vdso/gettimeofday.h | 191 ++++++++++++++++++++++++
> arch/x86/include/asm/vdso/vsyscall.h | 44 ++++++
> arch/x86/include/asm/vgtod.h | 75 +---------
> arch/x86/include/asm/vvar.h | 7 +-
> arch/x86/kernel/pvclock.c | 1 +
> 12 files changed, 284 insertions(+), 379 deletions(-)
> delete mode 100644 arch/x86/entry/vsyscall/vsyscall_gtod.c
> create mode 100644 arch/x86/include/asm/vdso/gettimeofday.h
> create mode 100644 arch/x86/include/asm/vdso/vsyscall.h
>
> To confirm my bisection was correct, I did a git checkout of 7ac8707479886c75f353bfb6a8273f423cfccb2. As expected, the
> kernel exhibited the problem I've described. However, a kernel built at the immediately preceding (parent?) commit
> (bfe801ebe84f42b4666d3f0adde90f504d56e35b) has a working network after a (>= 14minute) suspend/resume cycle.
>
> As the module name implies, I'm using wireless networking. The hardware is detected as "Intel(R) Wireless-AC 9260
> 160MHz, REV=0x324" by iwlwifi.
>
> I'm more than happy to provide additional diagnostics (but may need a little hand-holding) and to apply diagnostic or
> fix patches, but please cc me on any reply as I'm not subscribed to any of the kernel-related mailing lists.
>
> Chris
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3] KVM: arm: VGIC: properly initialise private IRQ affinity
From: Andre Przywara @ 2019-08-23 10:34 UTC (permalink / raw)
To: Marc Zyngier, Christoffer Dall
Cc: Zenghui Yu, Julien Grall, Dave Martin, linux-arm-kernel, kvmarm
At the moment we initialise the target *mask* of a virtual IRQ to the
VCPU it belongs to, even though this mask is only defined for GICv2 and
quickly runs out of bits for many GICv3 guests.
This behaviour triggers an UBSAN complaint for more than 32 VCPUs:
------
[ 5659.462377] UBSAN: Undefined behaviour in virt/kvm/arm/vgic/vgic-init.c:223:21
[ 5659.471689] shift exponent 32 is too large for 32-bit type 'unsigned int'
------
Also for GICv3 guests the reporting of TARGET in the "vgic-state" debugfs
dump is wrong, due to this very same problem.
Because there is no requirement to create the VGIC device before the
VCPUs (and QEMU actually does it the other way round), we can't safely
initialise mpidr or targets in kvm_vgic_vcpu_init(). But since we touch
every private IRQ for each VCPU anyway later (in vgic_init()), we can
just move the initialisation of those fields into there, where we
definitely know the VGIC type.
On the way make sure we really have either a VGICv2 or a VGICv3 device,
since the existing code is just checking for "VGICv3 or not", silently
ignoring the uninitialised case.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reported-by: Dave Martin <dave.martin@arm.com>
---
Changelog v2 .. v3:
- replace BUG_ON() with error return
Changelog v1 .. v2:
- drop private IRQ initialisation in kvm_vgic_vcpu_init()
- initialise private IRQs in vgic_init()
- explicitly checking for VGIC device being v2 or v3
virt/kvm/arm/vgic/vgic-init.c | 30 ++++++++++++++++++++----------
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
index 80127ca9269f..d67047fb261b 100644
--- a/virt/kvm/arm/vgic/vgic-init.c
+++ b/virt/kvm/arm/vgic/vgic-init.c
@@ -8,6 +8,7 @@
#include <linux/cpu.h>
#include <linux/kvm_host.h>
#include <kvm/arm_vgic.h>
+#include <asm/kvm_emulate.h>
#include <asm/kvm_mmu.h>
#include "vgic.h"
@@ -165,12 +166,18 @@ static int kvm_vgic_dist_init(struct kvm *kvm, unsigned int nr_spis)
irq->vcpu = NULL;
irq->target_vcpu = vcpu0;
kref_init(&irq->refcount);
- if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V2) {
+ switch (dist->vgic_model) {
+ case KVM_DEV_TYPE_ARM_VGIC_V2:
irq->targets = 0;
irq->group = 0;
- } else {
+ break;
+ case KVM_DEV_TYPE_ARM_VGIC_V3:
irq->mpidr = 0;
irq->group = 1;
+ break;
+ default:
+ kfree(dist->spis);
+ return -EINVAL;
}
}
return 0;
@@ -210,7 +217,6 @@ int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
irq->intid = i;
irq->vcpu = NULL;
irq->target_vcpu = vcpu;
- irq->targets = 1U << vcpu->vcpu_id;
kref_init(&irq->refcount);
if (vgic_irq_is_sgi(i)) {
/* SGIs */
@@ -220,11 +226,6 @@ int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
/* PPIs */
irq->config = VGIC_CONFIG_LEVEL;
}
-
- if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3)
- irq->group = 1;
- else
- irq->group = 0;
}
if (!irqchip_in_kernel(vcpu->kvm))
@@ -287,10 +288,19 @@ int vgic_init(struct kvm *kvm)
for (i = 0; i < VGIC_NR_PRIVATE_IRQS; i++) {
struct vgic_irq *irq = &vgic_cpu->private_irqs[i];
- if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3)
+ switch (dist->vgic_model) {
+ case KVM_DEV_TYPE_ARM_VGIC_V3:
irq->group = 1;
- else
+ irq->mpidr = kvm_vcpu_get_mpidr_aff(vcpu);
+ break;
+ case KVM_DEV_TYPE_ARM_VGIC_V2:
irq->group = 0;
+ irq->targets = 1U << idx;
+ break;
+ default:
+ ret = -EINVAL;
+ goto out;
+ }
}
}
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3] ARM: ftrace: remove mcount(),ftrace_caller_old() and ftrace_call_old()
From: Jisheng Zhang @ 2019-08-23 10:33 UTC (permalink / raw)
To: Steven Rostedt, Ingo Molnar, Russell King
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Commit d3c61619568c ("ARM: 8788/1: ftrace: remove old mcount support")
removed the old mcount support, but forget to remove these three
declarations. This patch removes them.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
Changes since v2:
- really remove mcount() declaration too. I made a mistake when sending out v2
Changes since v1:
- remove mcount() declaration too
arch/arm/include/asm/ftrace.h | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
index 18b0197f2384..48ec1d0337da 100644
--- a/arch/arm/include/asm/ftrace.h
+++ b/arch/arm/include/asm/ftrace.h
@@ -11,7 +11,6 @@
#define MCOUNT_INSN_SIZE 4 /* sizeof mcount call */
#ifndef __ASSEMBLY__
-extern void mcount(void);
extern void __gnu_mcount_nc(void);
#ifdef CONFIG_DYNAMIC_FTRACE
@@ -23,9 +22,6 @@ static inline unsigned long ftrace_call_adjust(unsigned long addr)
/* With Thumb-2, the recorded addresses have the lsb set */
return addr & ~1;
}
-
-extern void ftrace_caller_old(void);
-extern void ftrace_call_old(void);
#endif
#endif
--
2.23.0.rc1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 04/10] KVM: Implement kvm_put_guest()
From: Steven Price @ 2019-08-23 10:33 UTC (permalink / raw)
To: Sean Christopherson
Cc: Mark Rutland, Radim Krčmář, kvm, Suzuki K Pouloze,
Marc Zyngier, linux-doc, Russell King, linux-kernel, James Morse,
linux-arm-kernel, Catalin Marinas, Paolo Bonzini, Will Deacon,
kvmarm, Julien Thierry
In-Reply-To: <20190822162449.GF25467@linux.intel.com>
On 22/08/2019 17:24, Sean Christopherson wrote:
> On Thu, Aug 22, 2019 at 04:46:10PM +0100, Steven Price wrote:
>> On 22/08/2019 16:28, Sean Christopherson wrote:
>>> On Wed, Aug 21, 2019 at 04:36:50PM +0100, Steven Price wrote:
>>>> kvm_put_guest() is analogous to put_user() - it writes a single value to
>>>> the guest physical address. The implementation is built upon put_user()
>>>> and so it has the same single copy atomic properties.
>>>
>>> What you mean by "single copy atomic"? I.e. what guarantees does
>>> put_user() provide that __copy_to_user() does not?
>>
>> Single-copy atomicity is defined by the Arm architecture[1] and I'm not
>> going to try to go into the full details here, so this is a summary.
>>
>> For the sake of this feature what we care about is that the value
>> written/read cannot be "torn". In other words if there is a read (in
>> this case from another VCPU) that is racing with the write then the read
>> will either get the old value or the new value. It cannot return a
>> mixture. (This is of course assuming that the read is using a
>> single-copy atomic safe method).
>
> Thanks for the explanation. I assumed that's what you were referring to,
> but wanted to double check.
>
>> __copy_to_user() is implemented as a memcpy() and as such cannot provide
>> single-copy atomicity in the general case (the buffer could easily be
>> bigger than the architecture can guarantee).
>>
>> put_user() on the other hand is implemented (on arm64) as an explicit
>> store instruction and therefore is guaranteed by the architecture to be
>> single-copy atomic (i.e. another CPU cannot see a half-written value).
>
> I don't think kvm_put_guest() belongs in generic code, at least not with
> the current changelog explanation about it providing single-copy atomic
> semantics. AFAICT, the single-copy thing is very much an arm64
> implementation detail, e.g. the vast majority of 32-bit architectures,
> including x86, do not provide any guarantees, and x86-64 generates more
> or less the same code for put_user() and __copy_to_user() for 8-byte and
> smaller accesses.
>
> As an alternative to kvm_put_guest() entirely, is it an option to change
> arm64's raw_copy_to_user() to redirect to __put_user() for sizes that are
> constant at compile time and can be handled by __put_user()? That would
> allow using kvm_write_guest() to update stolen time, albeit with
> arguably an even bigger dependency on the uaccess implementation details.
I think it's important to in some way ensure that the desire that this
is a single write is shown. copy_to_user() is effectively
"setup();memcpy();finish();" and while a good memcpy() implementation
would be identical to put_user() there's a lot more room for this being
broken in the future by changes to the memcpy() implementation. (And I
don't want to require that memcpy() has to detect this case).
One suggestion is to call it something like kvm_put_guest_atomic() to
reflect the atomicity requirement. Presumably that would be based on a
new put_user_atomic() which architectures could override as necessary if
put_user() doesn't provide the necessary guarantees.
Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RESEND PATCH 5/5] arm64: dts: allwinner: orange-pi-3: Enable UART1 / Bluetooth
From: megous @ 2019-08-23 10:31 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Marcel Holtmann,
Johan Hedberg
Cc: Mark Rutland, devicetree, Ondrej Jirman, netdev, linux-kernel,
linux-bluetooth, David S. Miller, linux-arm-kernel
In-Reply-To: <20190823103139.17687-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
The board contains AP6256 WiFi/BT module that has its bluetooth part
connected to SoC's UART1 port. Enable this port, and add node for the
bluetooth device.
Bluetooth part is named bcm4345c5.
You'll need a BCM4345C5.hcd firmware file that can be found in the
Xulongs's repository for H6:
https://github.com/orangepi-xunlong/OrangePiH6_external/tree/master/ap6256
The driver expects the firmware at the following path relative to the
firmware directory:
brcm/BCM4345C5.hcd
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../dts/allwinner/sun50i-h6-orangepi-3.dts | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
index 49d954369087..a9e776446c35 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -15,6 +15,7 @@
aliases {
serial0 = &uart0;
+ serial1 = &uart1;
};
chosen {
@@ -271,6 +272,24 @@
status = "okay";
};
+/* There's the BT part of the AP6256 connected to that UART */
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm4345c5";
+ clocks = <&rtc 1>;
+ clock-names = "lpo";
+ device-wakeup-gpios = <&r_pio 1 2 GPIO_ACTIVE_HIGH>; /* PM2 */
+ host-wakeup-gpios = <&r_pio 1 1 GPIO_ACTIVE_HIGH>; /* PM1 */
+ shutdown-gpios = <&r_pio 1 4 GPIO_ACTIVE_HIGH>; /* PM4 */
+ max-speed = <1500000>;
+ };
+};
+
&usb2otg {
/*
* This board doesn't have a controllable VBUS even though it
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RESEND PATCH 2/5] bluetooth: bcm: Add support for loading firmware for BCM4345C5
From: megous @ 2019-08-23 10:31 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Marcel Holtmann,
Johan Hedberg
Cc: Mark Rutland, devicetree, Ondrej Jirman, netdev, linux-kernel,
linux-bluetooth, David S. Miller, linux-arm-kernel
In-Reply-To: <20190823103139.17687-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Detect BCM4345C5 and load a corresponding firmware file.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
Checkpatch reports a spurious error.
drivers/bluetooth/btbcm.c | 3 +++
drivers/bluetooth/hci_bcm.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/bluetooth/btbcm.c b/drivers/bluetooth/btbcm.c
index 124ef0a3e1dd..2d2e6d862068 100644
--- a/drivers/bluetooth/btbcm.c
+++ b/drivers/bluetooth/btbcm.c
@@ -23,6 +23,7 @@
#define BDADDR_BCM43430A0 (&(bdaddr_t) {{0xac, 0x1f, 0x12, 0xa0, 0x43, 0x43}})
#define BDADDR_BCM4324B3 (&(bdaddr_t) {{0x00, 0x00, 0x00, 0xb3, 0x24, 0x43}})
#define BDADDR_BCM4330B1 (&(bdaddr_t) {{0x00, 0x00, 0x00, 0xb1, 0x30, 0x43}})
+#define BDADDR_BCM4345C5 (&(bdaddr_t) {{0xac, 0x1f, 0x00, 0xc5, 0x45, 0x43}})
#define BDADDR_BCM43341B (&(bdaddr_t) {{0xac, 0x1f, 0x00, 0x1b, 0x34, 0x43}})
int btbcm_check_bdaddr(struct hci_dev *hdev)
@@ -73,6 +74,7 @@ int btbcm_check_bdaddr(struct hci_dev *hdev)
!bacmp(&bda->bdaddr, BDADDR_BCM2076B1) ||
!bacmp(&bda->bdaddr, BDADDR_BCM4324B3) ||
!bacmp(&bda->bdaddr, BDADDR_BCM4330B1) ||
+ !bacmp(&bda->bdaddr, BDADDR_BCM4345C5) ||
!bacmp(&bda->bdaddr, BDADDR_BCM43430A0) ||
!bacmp(&bda->bdaddr, BDADDR_BCM43341B)) {
bt_dev_info(hdev, "BCM: Using default device address (%pMR)",
@@ -332,6 +334,7 @@ static const struct bcm_subver_table bcm_uart_subver_table[] = {
{ 0x2122, "BCM4343A0" }, /* 001.001.034 */
{ 0x2209, "BCM43430A1" }, /* 001.002.009 */
{ 0x6119, "BCM4345C0" }, /* 003.001.025 */
+ { 0x6606, "BCM4345C5" }, /* 003.006.006 */
{ 0x230f, "BCM4356A2" }, /* 001.003.015 */
{ 0x220e, "BCM20702A1" }, /* 001.002.014 */
{ 0x4217, "BCM4329B1" }, /* 002.002.023 */
diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index 4d9de20bab7b..95c312ae94cf 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -1419,6 +1419,7 @@ static void bcm_serdev_remove(struct serdev_device *serdev)
#ifdef CONFIG_OF
static const struct of_device_id bcm_bluetooth_of_match[] = {
{ .compatible = "brcm,bcm20702a1" },
+ { .compatible = "brcm,bcm4345c5" },
{ .compatible = "brcm,bcm4330-bt" },
{ .compatible = "brcm,bcm43438-bt" },
{ },
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RESEND PATCH 3/5] bluetooth: hci_bcm: Give more time to come out of reset
From: megous @ 2019-08-23 10:31 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Marcel Holtmann,
Johan Hedberg
Cc: Mark Rutland, devicetree, Ondrej Jirman, netdev, linux-kernel,
linux-bluetooth, David S. Miller, linux-arm-kernel
In-Reply-To: <20190823103139.17687-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Some supported devices need more time to come out of reset (eg.
BCM4345C5 in AP6256).
I don't have/found a datasheet, so the value was arrive at
experimentally with the Oprange Pi 3 board. Without increased delay,
I got intermittent failures during probe. This is a Bluetooth 5.0
device, so maybe that's why it takes longer to initialize than the
others.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
drivers/bluetooth/hci_bcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index 95c312ae94cf..7646636f2d18 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -260,7 +260,7 @@ static int bcm_gpio_set_power(struct bcm_device *dev, bool powered)
}
/* wait for device to power on and come out of reset */
- usleep_range(10000, 20000);
+ usleep_range(100000, 120000);
dev->res_enabled = powered;
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RESEND PATCH 4/5] arm64: dts: allwinner: h6: Add pin configs for uart1
From: megous @ 2019-08-23 10:31 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Marcel Holtmann,
Johan Hedberg
Cc: Mark Rutland, devicetree, Ondrej Jirman, netdev, linux-kernel,
linux-bluetooth, David S. Miller, linux-arm-kernel
In-Reply-To: <20190823103139.17687-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Orange Pi 3 uses UART1 for bluetooth. Add pinconfigs so that we can use
them.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 67f920e0fc33..7657e816096b 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -298,6 +298,16 @@
pins = "PH0", "PH1";
function = "uart0";
};
+
+ uart1_pins: uart1-pins {
+ pins = "PG6", "PG7";
+ function = "uart1";
+ };
+
+ uart1_rts_cts_pins: uart1-rts-cts-pins {
+ pins = "PG8", "PG9";
+ function = "uart1";
+ };
};
gic: interrupt-controller@3021000 {
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RESEND PATCH 1/5] dt-bindings: net: Add compatible for BCM4345C5 bluetooth device
From: megous @ 2019-08-23 10:31 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Marcel Holtmann,
Johan Hedberg
Cc: Mark Rutland, devicetree, Ondrej Jirman, netdev, linux-kernel,
linux-bluetooth, David S. Miller, linux-arm-kernel
In-Reply-To: <20190823103139.17687-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
This is present in the AP6526 WiFi/Bluetooth 5.0 module.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
Documentation/devicetree/bindings/net/broadcom-bluetooth.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt b/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt
index c26f4e11037c..4fa00e2eafcf 100644
--- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt
+++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt
@@ -13,6 +13,7 @@ Required properties:
* "brcm,bcm20702a1"
* "brcm,bcm4330-bt"
* "brcm,bcm43438-bt"
+ * "brcm,bcm4345c5"
Optional properties:
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RESEND PATCH 0/5] Add bluetooth support for Orange Pi 3
From: megous @ 2019-08-23 10:31 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Marcel Holtmann,
Johan Hedberg
Cc: Mark Rutland, devicetree, Ondrej Jirman, netdev, linux-kernel,
linux-bluetooth, David S. Miller, linux-arm-kernel
From: Ondrej Jirman <megous@megous.com>
(Resend to add missing lists, sorry for the noise.)
This series implements bluetooth support for Xunlong Orange Pi 3 board.
The board uses AP6256 WiFi/BT 5.0 chip.
Summary of changes:
- add more delay to let initialize the chip
- let the kernel detect firmware file path
- add new compatible and update dt-bindings
- update Orange Pi 3 / H6 DTS
Please take a look.
thank you and regards,
Ondrej Jirman
Ondrej Jirman (5):
dt-bindings: net: Add compatible for BCM4345C5 bluetooth device
bluetooth: bcm: Add support for loading firmware for BCM4345C5
bluetooth: hci_bcm: Give more time to come out of reset
arm64: dts: allwinner: h6: Add pin configs for uart1
arm64: dts: allwinner: orange-pi-3: Enable UART1 / Bluetooth
.../bindings/net/broadcom-bluetooth.txt | 1 +
.../dts/allwinner/sun50i-h6-orangepi-3.dts | 19 +++++++++++++++++++
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 10 ++++++++++
drivers/bluetooth/btbcm.c | 3 +++
drivers/bluetooth/hci_bcm.c | 3 ++-
5 files changed, 35 insertions(+), 1 deletion(-)
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] ARM: ftrace: remove mcount(),ftrace_caller_old() and ftrace_call_old()
From: Jisheng Zhang @ 2019-08-23 10:30 UTC (permalink / raw)
To: Steven Rostedt, Ingo Molnar, Russell King
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Commit d3c61619568c ("ARM: 8788/1: ftrace: remove old mcount support")
removed the old mcount support, but forget to remove these three
declarations. This patch removes them.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
Changes since v1:
- remove mcount() declaration too
arch/arm/include/asm/ftrace.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
index 18b0197f2384..f67596427971 100644
--- a/arch/arm/include/asm/ftrace.h
+++ b/arch/arm/include/asm/ftrace.h
@@ -23,9 +23,6 @@ static inline unsigned long ftrace_call_adjust(unsigned long addr)
/* With Thumb-2, the recorded addresses have the lsb set */
return addr & ~1;
}
-
-extern void ftrace_caller_old(void);
-extern void ftrace_call_old(void);
#endif
#endif
--
2.23.0.rc1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [v1] arm64: dts: ls1028a: Remove some fixed-clock definiation
From: Wen He @ 2019-08-23 10:17 UTC (permalink / raw)
To: linux-devel, Rob Herring, Mark Rutland, Shawn Guo, devicetree,
linux-kernel, linux-arm-kernel
Cc: Wen He, leoyang.li
Replace pclk/aclk/mclk fixed-clock clock provider with platform clockgen
pre-divider provider, those clocks should be driven by the CGA_PLL2/2.
More details please refer Reference Manual.
Signed-off-by: Wen He <wen.he_1@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 17 ++---------------
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 024d6fbd07ea..0fa3e29cb603 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -90,20 +90,6 @@
clocks = <&osc_27m>;
};
- aclk: clock-axi {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <650000000>;
- clock-output-names= "aclk";
- };
-
- pclk: clock-apb {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <650000000>;
- clock-output-names= "pclk";
- };
-
reboot {
compatible ="syscon-reboot";
regmap = <&dcfg>;
@@ -885,7 +871,8 @@
interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
<0 223 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "DE", "SE";
- clocks = <&dpclk>, <&aclk>, <&aclk>, <&pclk>;
+ clocks = <&dpclk>, <&clockgen 2 2>, <&clockgen 2 2>,
+ <&clockgen 2 2>;
clock-names = "pxlclk", "mclk", "aclk", "pclk";
arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
arm,malidp-arqos-value = <0xd000d000>;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] arm64: dts: allwinner: orange-pi-3: Enable WiFi
From: Ondřej Jirman @ 2019-08-23 10:25 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, linux-kernel, Chen-Yu Tsai, Rob Herring,
linux-arm-kernel
In-Reply-To: <20190823100807.22heh2gahi7owo4e@flea>
Hello Maxime,
On Fri, Aug 23, 2019 at 12:08:07PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Fri, Aug 23, 2019 at 11:42:28AM +0200, megous@megous.com wrote:
> > From: Ondrej Jirman <megous@megous.com>
> >
> > Orange Pi 3 has AP6256 WiFi/BT module. WiFi part of the module is called
> > bcm43356 and can be used with the brcmfmac driver. The module is powered by
> > the two always on regulators (not AXP805).
> >
> > WiFi uses a PG port with 1.8V voltage level signals. SoC needs to be
> > configured so that it sets up an 1.8V input bias on this port. This is done
> > by the pio driver by reading the vcc-pg-supply voltage.
> >
> > You'll need a fw_bcm43456c5_ag.bin firmware file and nvram.txt
> > configuration that can be found in the Xulongs's repository for H6:
> >
> > https://github.com/orangepi-xunlong/OrangePiH6_external/tree/master/ap6256
> >
> > Mainline brcmfmac driver expects the firmware and nvram at the following
> > paths relative to the firmware directory:
> >
> > brcm/brcmfmac43456-sdio.bin
> > brcm/brcmfmac43456-sdio.txt
> >
> > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > ---
> >
> > Since RTC patches for H6 were merged, this can now go in too, if it looks ok.
> >
> > Other patches for this WiFi chip support were merged in previous cycles,
> > so this just needs enabling in DTS now.
> >
> > Sorry for the links in the commit log, but this information is useful,
> > even if the link itself goes bad. Any pointer what to google for
> > (file names, tree name) is great for anyone searching in the future.
>
> I understand, but this should (also?) be in the wiki. Please add it
> there too.
Added. Thank you.
http://linux-sunxi.org/Xunlong_Orange_Pi_3#Firmware_files
regards,
Ondrej
> > Please take a look.
> >
> > Thank you,
> > Ondrej
> >
> > .../dts/allwinner/sun50i-h6-orangepi-3.dts | 48 +++++++++++++++++++
> > 1 file changed, 48 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > index eda9d5f640b9..49d954369087 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > @@ -56,6 +56,34 @@
> > regulator-max-microvolt = <5000000>;
> > regulator-always-on;
> > };
> > +
> > + reg_vcc33_wifi: vcc33-wifi {
> > + /* Always on 3.3V regulator for WiFi and BT */
> > + compatible = "regulator-fixed";
> > + regulator-name = "vcc33-wifi";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-always-on;
> > + vin-supply = <®_vcc5v>;
> > + };
> > +
> > + reg_vcc_wifi_io: vcc-wifi-io {
> > + /* Always on 1.8V/300mA regulator for WiFi and BT IO */
> > + compatible = "regulator-fixed";
> > + regulator-name = "vcc-wifi-io";
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + regulator-always-on;
> > + vin-supply = <®_vcc33_wifi>;
> > + };
> > +
> > + wifi_pwrseq: wifi_pwrseq {
> > + compatible = "mmc-pwrseq-simple";
> > + clocks = <&rtc 1>;
> > + clock-names = "ext_clock";
> > + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PM3 */
> > + post-power-on-delay-ms = <200>;
> > + };
> > };
> >
> > &cpu0 {
> > @@ -91,6 +119,25 @@
> > status = "okay";
> > };
> >
> > +&mmc1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&mmc1_pins>;
>
> This is the default already. I've removed it and applied.
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 5/7] media: use the BIT() macro
From: Sylwester Nawrocki @ 2019-08-23 10:22 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Media Mailing List
Cc: Kate Stewart, Richard Fontana, Lad, Prabhakar, Thierry Reding,
Bluecherry Maintainers, Krzysztof Kozlowski, devel,
linux-samsung-soc, Michal Simek, Andrey Utkin, Jonathan Hunter,
Kukjin Kim, linux-arm-kernel, Ismael Luceno,
Mauro Carvalho Chehab, Benoit Parrot, linux-tegra,
Thomas Gleixner, Anton Sviridenko, Allison Randal, Andy Walls,
Hyun Kwon, Greg Kroah-Hartman, linux-renesas-soc, Kyungmin Park,
Kieran Bingham, Sakari Ailus, Hans Verkuil, Laurent Pinchart
In-Reply-To: <d6c04bf604084af63fec603b4afbd72c648e0394.1566553525.git.mchehab+samsung@kernel.org>
On 8/23/19 11:47, Mauro Carvalho Chehab wrote:
> There are lots of places where we're doing 1 << 31. That's bad,
> as, depending on the architecture, this has an undefined behavior.
>
> The BIT() macro is already prepared to handle this, so, let's
> just switch all "1 << number" macros by BIT(number) at the header files
> with has 1 << 31.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> v2:
> As suggested by Laurent:
> - Don't touch multi-bit masks
> - remove explicit casts
For:
drivers/media/platform/exynos4-is/fimc-lite-reg.h
drivers/media/platform/exynos4-is/fimc-reg.h
drivers/media/platform/s3c-camif/camif-regs.h
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] fix usb2 on rock64
From: Dan Johansen @ 2019-08-23 9:56 UTC (permalink / raw)
To: Tomohiro Mayama; +Cc: linux-rockchip, linux-arm-kernel
In-Reply-To: <991ac738-1f5d-8bbd-9c0e-a7e6c05514d9@iris.mystia.org>
Tomohiro Mayama skrev den 2019-03-08 11:48:
> Hello Dan,
>
> On 2019/03/08 16:35, Dan Johansen wrote:
>> - gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>;
>> + gpio = <&gpio0 RK_PD3 GPIO_ACTIVE_HIGH>;
>
> According to Robin's advice by reading the schematic, correct GPIO pin
> assignment is RK_PA2, but GPIO_ACTIVE_LOW. This fixed the USB problem
> for me.
>
> Please see the following thread:
> https://lists.infradead.org/pipermail/linux-rockchip/2019-March/023298.html
>
> Also please see this patch:
> https://lists.infradead.org/pipermail/linux-rockchip/2019-March/023300.html
>
> Or won't your problem be fixed with this patch?
>
> Regards,
> Tomohiro
Ah, didn't see that one.
Yes it does.
Sorry. Please remove this patch submission.
--
Sincerely
Dan "Strit" Johansen
Project Lead on the Manjaro ARM project
https://www.manjaro.org
Catch me on:
Mastodon: @strit@mastodon.social
Matrix: @strit:matrix.org
Wire: @strit
Email: strit@manjaro.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: orange-pi-3: Enable WiFi
From: Chen-Yu Tsai @ 2019-08-23 10:10 UTC (permalink / raw)
To: Maxime Ripard
Cc: Ondřej Jirman, Mark Rutland, devicetree, linux-kernel,
Rob Herring, linux-arm-kernel
In-Reply-To: <20190823100807.22heh2gahi7owo4e@flea>
On Fri, Aug 23, 2019 at 6:08 PM Maxime Ripard <mripard@kernel.org> wrote:
>
> Hi,
>
> On Fri, Aug 23, 2019 at 11:42:28AM +0200, megous@megous.com wrote:
> > From: Ondrej Jirman <megous@megous.com>
> >
> > Orange Pi 3 has AP6256 WiFi/BT module. WiFi part of the module is called
> > bcm43356 and can be used with the brcmfmac driver. The module is powered by
> > the two always on regulators (not AXP805).
> >
> > WiFi uses a PG port with 1.8V voltage level signals. SoC needs to be
> > configured so that it sets up an 1.8V input bias on this port. This is done
> > by the pio driver by reading the vcc-pg-supply voltage.
> >
> > You'll need a fw_bcm43456c5_ag.bin firmware file and nvram.txt
> > configuration that can be found in the Xulongs's repository for H6:
> >
> > https://github.com/orangepi-xunlong/OrangePiH6_external/tree/master/ap6256
> >
> > Mainline brcmfmac driver expects the firmware and nvram at the following
> > paths relative to the firmware directory:
> >
> > brcm/brcmfmac43456-sdio.bin
> > brcm/brcmfmac43456-sdio.txt
> >
> > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > ---
> >
> > Since RTC patches for H6 were merged, this can now go in too, if it looks ok.
> >
> > Other patches for this WiFi chip support were merged in previous cycles,
> > so this just needs enabling in DTS now.
> >
> > Sorry for the links in the commit log, but this information is useful,
> > even if the link itself goes bad. Any pointer what to google for
> > (file names, tree name) is great for anyone searching in the future.
>
> I understand, but this should (also?) be in the wiki. Please add it
> there too.
>
> > Please take a look.
> >
> > Thank you,
> > Ondrej
> >
> > .../dts/allwinner/sun50i-h6-orangepi-3.dts | 48 +++++++++++++++++++
> > 1 file changed, 48 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > index eda9d5f640b9..49d954369087 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > @@ -56,6 +56,34 @@
> > regulator-max-microvolt = <5000000>;
> > regulator-always-on;
> > };
> > +
> > + reg_vcc33_wifi: vcc33-wifi {
> > + /* Always on 3.3V regulator for WiFi and BT */
> > + compatible = "regulator-fixed";
> > + regulator-name = "vcc33-wifi";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-always-on;
> > + vin-supply = <®_vcc5v>;
> > + };
> > +
> > + reg_vcc_wifi_io: vcc-wifi-io {
> > + /* Always on 1.8V/300mA regulator for WiFi and BT IO */
> > + compatible = "regulator-fixed";
> > + regulator-name = "vcc-wifi-io";
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + regulator-always-on;
> > + vin-supply = <®_vcc33_wifi>;
> > + };
> > +
> > + wifi_pwrseq: wifi_pwrseq {
IIRC we shouldn't use underscores in node names. Maxime can you fix that up?
ChenYu
> > + compatible = "mmc-pwrseq-simple";
> > + clocks = <&rtc 1>;
> > + clock-names = "ext_clock";
> > + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PM3 */
> > + post-power-on-delay-ms = <200>;
> > + };
> > };
> >
> > &cpu0 {
> > @@ -91,6 +119,25 @@
> > status = "okay";
> > };
> >
> > +&mmc1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&mmc1_pins>;
>
> This is the default already. I've removed it and applied.
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: orange-pi-3: Enable WiFi
From: Maxime Ripard @ 2019-08-23 10:08 UTC (permalink / raw)
To: megous
Cc: Mark Rutland, devicetree, linux-kernel, Chen-Yu Tsai, Rob Herring,
linux-arm-kernel
In-Reply-To: <20190823094228.6540-1-megous@megous.com>
[-- Attachment #1.1: Type: text/plain, Size: 3198 bytes --]
Hi,
On Fri, Aug 23, 2019 at 11:42:28AM +0200, megous@megous.com wrote:
> From: Ondrej Jirman <megous@megous.com>
>
> Orange Pi 3 has AP6256 WiFi/BT module. WiFi part of the module is called
> bcm43356 and can be used with the brcmfmac driver. The module is powered by
> the two always on regulators (not AXP805).
>
> WiFi uses a PG port with 1.8V voltage level signals. SoC needs to be
> configured so that it sets up an 1.8V input bias on this port. This is done
> by the pio driver by reading the vcc-pg-supply voltage.
>
> You'll need a fw_bcm43456c5_ag.bin firmware file and nvram.txt
> configuration that can be found in the Xulongs's repository for H6:
>
> https://github.com/orangepi-xunlong/OrangePiH6_external/tree/master/ap6256
>
> Mainline brcmfmac driver expects the firmware and nvram at the following
> paths relative to the firmware directory:
>
> brcm/brcmfmac43456-sdio.bin
> brcm/brcmfmac43456-sdio.txt
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> ---
>
> Since RTC patches for H6 were merged, this can now go in too, if it looks ok.
>
> Other patches for this WiFi chip support were merged in previous cycles,
> so this just needs enabling in DTS now.
>
> Sorry for the links in the commit log, but this information is useful,
> even if the link itself goes bad. Any pointer what to google for
> (file names, tree name) is great for anyone searching in the future.
I understand, but this should (also?) be in the wiki. Please add it
there too.
> Please take a look.
>
> Thank you,
> Ondrej
>
> .../dts/allwinner/sun50i-h6-orangepi-3.dts | 48 +++++++++++++++++++
> 1 file changed, 48 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> index eda9d5f640b9..49d954369087 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> @@ -56,6 +56,34 @@
> regulator-max-microvolt = <5000000>;
> regulator-always-on;
> };
> +
> + reg_vcc33_wifi: vcc33-wifi {
> + /* Always on 3.3V regulator for WiFi and BT */
> + compatible = "regulator-fixed";
> + regulator-name = "vcc33-wifi";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + vin-supply = <®_vcc5v>;
> + };
> +
> + reg_vcc_wifi_io: vcc-wifi-io {
> + /* Always on 1.8V/300mA regulator for WiFi and BT IO */
> + compatible = "regulator-fixed";
> + regulator-name = "vcc-wifi-io";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + vin-supply = <®_vcc33_wifi>;
> + };
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + clocks = <&rtc 1>;
> + clock-names = "ext_clock";
> + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PM3 */
> + post-power-on-delay-ms = <200>;
> + };
> };
>
> &cpu0 {
> @@ -91,6 +119,25 @@
> status = "okay";
> };
>
> +&mmc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins>;
This is the default already. I've removed it and applied.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox