* [PATCH 0/9] Flash Memory Protector Support
From: boojin.kim @ 2019-08-21 6:42 UTC (permalink / raw)
To: 'Herbert Xu', 'David S. Miller',
'Eric Biggers', 'Theodore Y. Ts'o',
'Chao Yu', 'Jaegeuk Kim',
'Andreas Dilger', 'Theodore Ts'o', dm-devel,
'Mike Snitzer', 'Alasdair Kergon',
'Jens Axboe', 'Krzysztof Kozlowski',
'Kukjin Kim', 'Jaehoon Chung',
'Ulf Hansson', linux-crypto, linux-kernel, linux-fscrypt,
linux-mmc, linux-samsung-soc, linux-block, linux-ext4,
linux-f2fs-devel, linux-samsung-soc, linux-arm-kernel,
linux-fsdevel
In-Reply-To: <CGME20190821064206epcas2p1d1bcaae142416506bcedb3201d9a6658@epcas2p1.samsung.com>
Exynos has a H/W block called FMP (Flash Memory Protector) to protect data
stored on storage device.
FMP interworks with the storage controller to encrypt a data before writing
to the storage device and decrypt the data after reading from storage
device.
FMP is a kind of ICE (inline crypto engines), which is generally known
as being used for the above role.
To use FMP, the modification of various layers such as Fscrypt, ext4, f2fs,
DM-crypt, storage controller driver and block is required.
FMP solution introduces a new diskcipher similar to the existing skcipher
in crypo API in order to minimize the modification of these layers and
to improve the code readability.
This patchset includes the following for using FMP:
- Diskcipher and FMP are added to crypto API.
- The crypto users such as dm-crypt and fscrypt are modified to support
diskcipher.
- The bio submitters such as f2fs, ext4, dm-crypt are modified to support
diskcipher.
- Block layer is modified to pass diskcipher to storage controller driver.
- Storage controller driver is modified to support crypto operation.
Exynos FMP solution consists of Diskcipher and FMP driver.
Diskcipher is a symmetric key cipher of crypto API that supports inline
crypto engine like FMP.
FMP driver is a cipher algorithm running on diskcipher.
FMP driver registers 'cbc(aes)-disk' and 'xts(aes)-disk' algorithms to
crypto API.
FMP can be tested with various test vectors in testmgr of crypto API.
When encrypting using FMP, additional control is required to deliver and
manage encryption information between encryption users (fscrypt, DM-crypt)
and FMP drivers. Diskcipher provides this control.
The encryption using FMP is made up of 4 steps.
The first step is to assign a password and set a key.
Encryption users such as Fscrypt or DM-crypt assign diskcipher, and set key
to the diskcipher.
The second step is to deliver diskcipher that has crypto information to
storage drivers such as UFS and MMC. BIO is used to this delivery.
The BIO submitters, such as ext4, f2fs and DM-crypt, checks if there is
diskcipher in crypto configuration before issuing BIO. If there are
diskcipher, the submitter sets it to BIO.
In addition, the BIO submitter skips the task of encrypting data before BIO
and decrypting data after BIO is completed.
In the third step, the storage driver gets the diskcipher from the BIO and
requests the FMP to encrypt.
In the final step, the FMP extracts crypto information from the diskcipher
and writes it in the descriptor area allocated for FMP H/W.
The FMP H/W uses the descriptor of the storage controller to contain crypto
information. So the descriptor of storage controller should be expanded
for FMP.
Boojin Kim (9):
crypt: Add diskcipher
crypto: fmp: add Flash Memory Protector driver
mmc: dw_mmc: support crypto operation
mmc: dw_mmc-exynos: support FMP
block: support diskcipher
dm crypt: support diskcipher
fscrypt: support diskcipher
fs: ext4: support diskcipher
fs: f2fs: support diskcipher
block/bio.c | 1 +
block/blk-merge.c | 19 +-
block/bounce.c | 5 +-
crypto/Kconfig | 9 +
crypto/Makefile | 1 +
crypto/diskcipher.c | 349 +++++++++++++++++++++++
crypto/testmgr.c | 157 +++++++++++
drivers/crypto/Kconfig | 2 +
drivers/crypto/Makefile | 1 +
drivers/crypto/fmp/Kconfig | 13 +
drivers/crypto/fmp/Makefile | 1 +
drivers/crypto/fmp/fmp.c | 595
+++++++++++++++++++++++++++++++++++++++
drivers/crypto/fmp/fmp_crypt.c | 243 ++++++++++++++++
drivers/crypto/fmp/fmp_test.c | 310 ++++++++++++++++++++
drivers/crypto/fmp/fmp_test.h | 30 ++
drivers/md/dm-crypt.c | 112 +++++++-
drivers/mmc/host/Kconfig | 8 +
drivers/mmc/host/dw_mmc-exynos.c | 62 ++++
drivers/mmc/host/dw_mmc.c | 48 +++-
drivers/mmc/host/dw_mmc.h | 6 +
fs/buffer.c | 2 +
fs/crypto/bio.c | 43 ++-
fs/crypto/fscrypt_private.h | 28 +-
fs/crypto/keysetup.c | 60 +++-
fs/crypto/keysetup_v1.c | 2 +-
fs/ext4/inode.c | 39 ++-
fs/ext4/page-io.c | 8 +-
fs/ext4/readpage.c | 7 +
fs/f2fs/data.c | 98 ++++++-
fs/f2fs/f2fs.h | 2 +-
include/crypto/diskcipher.h | 245 ++++++++++++++++
include/crypto/fmp.h | 324 +++++++++++++++++++++
include/linux/bio.h | 10 +
include/linux/blk_types.h | 4 +
include/linux/bvec.h | 3 +
include/linux/crypto.h | 1 +
include/linux/fscrypt.h | 19 ++
include/uapi/linux/fscrypt.h | 2 +
tools/include/uapi/linux/fs.h | 1 +
39 files changed, 2837 insertions(+), 33 deletions(-)
create mode 100644 crypto/diskcipher.c
create mode 100644 drivers/crypto/fmp/Kconfig
create mode 100644 drivers/crypto/fmp/Makefile
create mode 100644 drivers/crypto/fmp/fmp.c
create mode 100644 drivers/crypto/fmp/fmp_crypt.c
create mode 100644 drivers/crypto/fmp/fmp_test.c
create mode 100644 drivers/crypto/fmp/fmp_test.h
create mode 100644 include/crypto/diskcipher.h
create mode 100644 include/crypto/fmp.h
--
2.7.4
_______________________________________________
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 v8 2/3] fdt: add support for rng-seed
From: Ard Biesheuvel @ 2019-08-21 6:39 UTC (permalink / raw)
To: Hsin-Yi Wang
Cc: Mark Rutland, Devicetree List, Theodore Y. Ts'o, Yu Zhao,
Kees Cook, Catalin Marinas, Stephen Boyd, Will Deacon, lkml,
Mike Rapoport, Jun Yao, Miles Chen, Rob Herring, James Morse,
Andrew Murray, Andrew Morton, Laura Abbott, Frank Rowand,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Robin Murphy
In-Reply-To: <CAJMQK-hdYz+pW5QL41nXkZAX1qiRynaWg7cne48qCaQsuPrSCg@mail.gmail.com>
On Wed, 21 Aug 2019 at 08:57, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
>
> Then we'd still use add_device_randomness() in case that bootloader
> provides weak entropy.
>
(please don't top post)
Whether to trust the firmware provided entropy is a policy decision,
and typically, we try to avoid dictating policy in the kernel, and
instead, we try to provide a sane default but give the user control
over it.
So in this case, we should probably introduce
add_firmware_randomness() with a Kconfig/cmdline option pair to decide
whether it should be trusted or not (or reuse the one we have for
trusting RDRAND etc)
> On Tue, Aug 20, 2019 at 7:14 PM Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
> >
> > On Tue, 20 Aug 2019 at 10:43, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > >
> > > Hi Ted,
> > >
> > > Thanks for raising this question.
> > >
> > > For UEFI based system, they have a config table that carries rng seed
> > > and can be passed to device randomness. However, they also use
> > > add_device_randomness (not sure if it's the same reason that they
> > > can't guarantee _all_ bootloader can be trusted)
> >
> > The config table is actually a Linux invention: it is populated by the
> > EFI stub code (which is part of the kernel) based on the output of a
> > call into the EFI_RNG_PROTOCOL, which is defined in the UEFI spec, but
> > optional and not widely available.
> >
> > I have opted for add_device_randomness() since there is no way to
> > establish the quality level of the output of EFI_RNG_PROTOCOL, and so
> > it is currently only used to prevent the bootup state of the entropy
> > pool to be too predictable, and the output does not contribute to the
> > entropy estimate kept by the RNG core.
> >
> >
> > > This patch is to let DT based system also have similar features, which
> > > can make initial random number stronger. (We only care initial
> > > situation here, since more entropy would be added to kernel as time
> > > goes on )
> > >
> > > Conservatively, we can use add_device_randomness() as well, which
> > > would pass buffer to crng_slow_load() instead of crng_fast_load().
> > > But I think we should trust bootloader here. Whoever wants to use this
> > > feature should make sure their bootloader can pass valid (random
> > > enough) seeds. If they are not sure, they can just don't add the
> > > property to DT.
> >
> > It is the firmware that adds the property to the DT, not the user.
_______________________________________________
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 5/8] soc: ti: omap-prm: add omap4 PRM data
From: Tero Kristo @ 2019-08-21 6:38 UTC (permalink / raw)
To: Suman Anna, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <ed0ec707-ddea-cbfa-ecdf-99faeb770f3f@ti.com>
On 20.8.2019 20.23, Suman Anna wrote:
> On 8/20/19 2:52 AM, Tero Kristo wrote:
>> On 20.8.2019 2.08, Suman Anna wrote:
>>> On 8/7/19 2:48 AM, Tero Kristo wrote:
>>>> Add PRM data for omap4 family of SoCs.
>>>>
>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>> ---
>>>> drivers/soc/ti/omap_prm.c | 20 ++++++++++++++++++++
>>>> 1 file changed, 20 insertions(+)
>>>>
>>>> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
>>>> index 870515e3..9b8d5945 100644
>>>> --- a/drivers/soc/ti/omap_prm.c
>>>> +++ b/drivers/soc/ti/omap_prm.c
>>>> @@ -54,7 +54,27 @@ struct omap_reset_data {
>>>> #define OMAP_PRM_NO_RSTST BIT(0)
>>>> +struct omap_prm_data omap4_prm_data[] = {
>>>
>>> static const
>>
>> Will fix this and rest of the similar comments.
>>
>> -Tero
>>
>>>
>>> regards
>>> Suman
>>>
>>>> + { .name = "mpu", .base = 0x4a306300, .pwstst = 0x4 },
>>>> + { .name = "tesla", .base = 0x4a306400, .pwstst = 0x4, .rstctl =
>>>> 0x10, .rstst = 0x14 },
>>>> + { .name = "abe", .base = 0x4a306500, .pwstst = 0x4 },
>>>> + { .name = "always_on_core", .base = 0x4a306600, .pwstst = 0x4 },
>>>> + { .name = "core", .base = 0x4a306700, .pwstst = 0x4, .rstctl =
>>>> 0x210, .rstst = 0x214 },
>>>> + { .name = "ivahd", .base = 0x4a306f00, .pwstst = 0x4, .rstctl =
>>>> 0x10, .rstst = 0x14 },
>>>> + { .name = "cam", .base = 0x4a307000, .pwstst = 0x4 },
>>>> + { .name = "dss", .base = 0x4a307100, .pwstst = 0x4 },
>>>> + { .name = "gfx", .base = 0x4a307200, .pwstst = 0x4 },
>>>> + { .name = "l3init", .base = 0x4a307300, .pwstst = 0x4 },
>>>> + { .name = "l4per", .base = 0x4a307400, .pwstst = 0x4 },
>>>> + { .name = "cefuse", .base = 0x4a307600, .pwstst = 0x4 },
>>>> + { .name = "wkup", .base = 0x4a307700, .pwstst = 0x4 },
>>>> + { .name = "emu", .base = 0x4a307900, .pwstst = 0x4 },
>>>> + { .name = "device", .base = 0x4a307b00, .rstctl = 0x0, .rstst =
>>>> 0x4 },
>
> So, looks like you are using pwstctrl as 0 by default, but some of them
> will neither have pwstctrl or pwstst like "device" PRM here. Is the plan
> to use -1 for the fields, or a flags field?
Multiple paths are possible, I will see what makes most sense once I
implement it.
-Tero
>
> regards
> Suman
>
>>>> + { },
>>>> +};
>>>> +
>>>> static const struct of_device_id omap_prm_id_table[] = {
>>>> + { .compatible = "ti,omap4-prm-inst", .data = omap4_prm_data },
>>>> { },
>>>> };
>>>>
>>>
>>
>> --
>
--
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: [PATCH] efi/arm: fix allocation failure when reserving the kernel base
From: Ard Biesheuvel @ 2019-08-21 6:35 UTC (permalink / raw)
To: Chester Lin
Cc: Juergen Gross, linux-efi@vger.kernel.org,
guillaume.gardet@arm.com, linux-kernel@vger.kernel.org,
Russell King - ARM Linux admin, Joey Lee, geert@linux-m68k.org,
ren_guo@c-sky.com, Gary Lin, akpm@linux-foundation.org,
rppt@linux.ibm.com, mingo@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190821061027.GA2828@linux-8mug>
On Wed, 21 Aug 2019 at 09:11, Chester Lin <clin@suse.com> wrote:
>
> On Tue, Aug 20, 2019 at 03:28:25PM +0300, Ard Biesheuvel wrote:
> > On Tue, 20 Aug 2019 at 14:56, Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > >
> > > On Fri, Aug 02, 2019 at 05:38:54AM +0000, Chester Lin wrote:
> > > > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > > > index f3ce34113f89..909b11ba48d8 100644
> > > > --- a/arch/arm/mm/mmu.c
> > > > +++ b/arch/arm/mm/mmu.c
> > > > @@ -1184,6 +1184,9 @@ void __init adjust_lowmem_bounds(void)
> > > > phys_addr_t block_start = reg->base;
> > > > phys_addr_t block_end = reg->base + reg->size;
> > > >
> > > > + if (memblock_is_nomap(reg))
> > > > + continue;
> > > > +
> > > > if (reg->base < vmalloc_limit) {
> > > > if (block_end > lowmem_limit)
> > > > /*
> > >
> > > I think this hunk is sane - if the memory is marked nomap, then it isn't
> > > available for the kernel's use, so as far as calculating where the
> > > lowmem/highmem boundary is, it effectively doesn't exist and should be
> > > skipped.
> > >
> >
> > I agree.
> >
> > Chester, could you explain what you need beyond this change (and my
> > EFI stub change involving TEXT_OFFSET) to make things work on the
> > RPi2?
> >
>
> Hi Ard,
>
> In fact I am working with Guillaume to try booting zImage kernel and openSUSE
> from grub2.04 + arm32-efistub so that's why we get this issue on RPi2, which is
> one of the test machines we have. However we want a better solution for all
> cases but not just RPi2 since we don't want to affect other platforms as well.
>
Thanks Chester, but that doesn't answer my question.
Your fix is a single patch that changes various things that are only
vaguely related. We have already identified that we need to take
TEXT_OFFSET (minus some space used by the swapper page tables) into
account into the EFI stub if we want to ensure compatibility with many
different platforms, and as it turns out, this applies not only to
RPi2 but to other platforms as well, most notably the ones that
require a TEXT_OFFSET of 0x208000, since they also have reserved
regions at the base of RAM.
My question was what else we need beyond:
- the EFI stub TEXT_OFFSET fix [0]
- the change to disregard NOMAP memblocks in adjust_lowmem_bounds()
- what else???
[0] https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/commit/?h=next&id=0eb7bad595e52666b642a02862ad996a0f9bfcc0
_______________________________________________
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] efi/arm: fix allocation failure when reserving the kernel base
From: Chester Lin @ 2019-08-21 6:10 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Juergen Gross, Joey Lee, linux-efi@vger.kernel.org,
guillaume.gardet@arm.com, linux-kernel@vger.kernel.org,
Russell King - ARM Linux admin, rppt@linux.ibm.com, Chester Lin,
geert@linux-m68k.org, ren_guo@c-sky.com, Gary Lin,
akpm@linux-foundation.org, mingo@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAKv+Gu_0wFw5Mjpdw7BEY7ewgetNgU=Ff1uvAsn0iHmJouyKqw@mail.gmail.com>
On Tue, Aug 20, 2019 at 03:28:25PM +0300, Ard Biesheuvel wrote:
> On Tue, 20 Aug 2019 at 14:56, Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Fri, Aug 02, 2019 at 05:38:54AM +0000, Chester Lin wrote:
> > > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > > index f3ce34113f89..909b11ba48d8 100644
> > > --- a/arch/arm/mm/mmu.c
> > > +++ b/arch/arm/mm/mmu.c
> > > @@ -1184,6 +1184,9 @@ void __init adjust_lowmem_bounds(void)
> > > phys_addr_t block_start = reg->base;
> > > phys_addr_t block_end = reg->base + reg->size;
> > >
> > > + if (memblock_is_nomap(reg))
> > > + continue;
> > > +
> > > if (reg->base < vmalloc_limit) {
> > > if (block_end > lowmem_limit)
> > > /*
> >
> > I think this hunk is sane - if the memory is marked nomap, then it isn't
> > available for the kernel's use, so as far as calculating where the
> > lowmem/highmem boundary is, it effectively doesn't exist and should be
> > skipped.
> >
>
> I agree.
>
> Chester, could you explain what you need beyond this change (and my
> EFI stub change involving TEXT_OFFSET) to make things work on the
> RPi2?
>
Hi Ard,
In fact I am working with Guillaume to try booting zImage kernel and openSUSE
from grub2.04 + arm32-efistub so that's why we get this issue on RPi2, which is
one of the test machines we have. However we want a better solution for all
cases but not just RPi2 since we don't want to affect other platforms as well.
Regards,
Chester
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH v5 09/15] clk: sunxi-ng: h6: Allow I2S to change parent rate
From: Chen-Yu Tsai @ 2019-08-21 6:01 UTC (permalink / raw)
To: Code Kipper
Cc: Jernej Skrabec, Linux-ALSA, linux-kernel, Liam Girdwood,
Andrea Venturi (pers), linux-sunxi, Mark Brown, Maxime Ripard,
linux-arm-kernel
In-Reply-To: <CAEKpxBnxf=iejk887A7qFkzt3BXVxiRS1PeA45aZYR9DsBAU4Q@mail.gmail.com>
On Wed, Aug 21, 2019 at 1:52 PM Code Kipper <codekipper@gmail.com> wrote:
>
> Thanks....I've added to my next patch series but if you could add it
> when applying that would be great.
Please reply with an explicit SoB to put it on the record.
ChenYu
> BR,
> CK
>
> On Wed, 21 Aug 2019 at 06:07, Chen-Yu Tsai <wens@csie.org> wrote:
> >
> > On Wed, Aug 14, 2019 at 2:09 PM <codekipper@gmail.com> wrote:
> > >
> > > From: Jernej Skrabec <jernej.skrabec@siol.net>
> > >
> > > I2S doesn't work if parent rate couldn't be change. Difference between
> > > wanted and actual rate is too big.
> > >
> > > Fix this by adding CLK_SET_RATE_PARENT flag to I2S clocks.
> > >
> > > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >
> > This lacks your SoB. Please reply and I can add it when applying.
> >
> > ChenYu
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CAEKpxBnxf%3Diejk887A7qFkzt3BXVxiRS1PeA45aZYR9DsBAU4Q%40mail.gmail.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 v8 2/3] fdt: add support for rng-seed
From: Hsin-Yi Wang @ 2019-08-21 5:57 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Mark Rutland, Devicetree List, Theodore Y. Ts'o, Yu Zhao,
Kees Cook, Catalin Marinas, Stephen Boyd, Will Deacon, lkml,
Mike Rapoport, Jun Yao, Miles Chen, Rob Herring, James Morse,
Andrew Murray, Andrew Morton, Laura Abbott, Frank Rowand,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Robin Murphy
In-Reply-To: <CAKv+Gu_qJUU2hRujjv6e5yPqPQXRXokBU_2mSGD3civ2d2+xhw@mail.gmail.com>
Then we'd still use add_device_randomness() in case that bootloader
provides weak entropy.
On Tue, Aug 20, 2019 at 7:14 PM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
>
> On Tue, 20 Aug 2019 at 10:43, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> >
> > Hi Ted,
> >
> > Thanks for raising this question.
> >
> > For UEFI based system, they have a config table that carries rng seed
> > and can be passed to device randomness. However, they also use
> > add_device_randomness (not sure if it's the same reason that they
> > can't guarantee _all_ bootloader can be trusted)
>
> The config table is actually a Linux invention: it is populated by the
> EFI stub code (which is part of the kernel) based on the output of a
> call into the EFI_RNG_PROTOCOL, which is defined in the UEFI spec, but
> optional and not widely available.
>
> I have opted for add_device_randomness() since there is no way to
> establish the quality level of the output of EFI_RNG_PROTOCOL, and so
> it is currently only used to prevent the bootup state of the entropy
> pool to be too predictable, and the output does not contribute to the
> entropy estimate kept by the RNG core.
>
>
> > This patch is to let DT based system also have similar features, which
> > can make initial random number stronger. (We only care initial
> > situation here, since more entropy would be added to kernel as time
> > goes on )
> >
> > Conservatively, we can use add_device_randomness() as well, which
> > would pass buffer to crng_slow_load() instead of crng_fast_load().
> > But I think we should trust bootloader here. Whoever wants to use this
> > feature should make sure their bootloader can pass valid (random
> > enough) seeds. If they are not sure, they can just don't add the
> > property to DT.
>
> It is the firmware that adds the property to the DT, not the user.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Build regression in Linux 5.3-rc5 with CONFIG_XEN=y
From: Stefan Wahren @ 2019-08-21 5:56 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: iommu, Robin Murphy, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20190820012415.GA21178@lst.de>
Am 20.08.19 um 03:24 schrieb Christoph Hellwig:
> Hi Stefan,
>
> please try the patch below.
>
> ---
> From e0570628d96faa50ebfc94ce8e545968336db225 Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig <hch@lst.de>
> Date: Tue, 20 Aug 2019 10:08:38 +0900
> Subject: arm: select the dma-noncoherent symbols for all swiotlb builds
>
> We need to provide the arch hooks for non-coherent dma-direct
> and swiotlb for all swiotlb builds, not just when LPAS is enabled.
> Without that the Xen build that selects SWIOTLB indirectly through
> SWIOTLB_XEN fails to build.
>
> Fixes: ad3c7b18c5b3 ("arm: use swiotlb for bounce buffering on LPAE configs")
> Reported-by: Stefan Wahren <wahrenst@gmx.net>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Tested-by: Stefan Wahren <wahrenst@gmx.net>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 7/7] ARM: configs: aspeed_g5: Enable AST2600
From: Joel Stanley @ 2019-08-21 5:55 UTC (permalink / raw)
To: Rob Herring, Arnd Bergmann, Olof Johansson
Cc: Mark Rutland, devicetree, Ryan Chen, linux-aspeed, Andrew Jeffery,
Cédric Le Goater, linux-arm-kernel
In-Reply-To: <20190821055530.8720-1-joel@jms.id.au>
CONFIG_STRICT_KERNEL_RWX is enabled by default with ARMv7.
Turn on HIGHMEM as the EVB has 2GB of RAM, and not all is usable without
hihgmem.
The SoC contains Cortex A7 supporting VFP and has two CPUs.
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
arch/arm/configs/aspeed_g5_defconfig | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig
index 426d8e0c9890..597536cc9573 100644
--- a/arch/arm/configs/aspeed_g5_defconfig
+++ b/arch/arm/configs/aspeed_g5_defconfig
@@ -21,21 +21,26 @@ CONFIG_PERF_EVENTS=y
CONFIG_SLAB=y
CONFIG_SLAB_FREELIST_RANDOM=y
CONFIG_ARCH_MULTI_V6=y
-# CONFIG_ARCH_MULTI_V7 is not set
CONFIG_ARCH_ASPEED=y
CONFIG_MACH_ASPEED_G5=y
+CONFIG_MACH_ASPEED_G6=y
# CONFIG_CACHE_L2X0 is not set
+CONFIG_SMP=y
+# CONFIG_ARM_CPU_TOPOLOGY is not set
CONFIG_VMSPLIT_2G=y
+CONFIG_NR_CPUS=2
+CONFIG_HIGHMEM=y
CONFIG_UACCESS_WITH_MEMCPY=y
CONFIG_SECCOMP=y
# CONFIG_ATAGS is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_KEXEC=y
-# CONFIG_SUSPEND is not set
+CONFIG_VFP=y
+CONFIG_NEON=y
+CONFIG_KERNEL_MODE_NEON=y
CONFIG_FIRMWARE_MEMMAP=y
CONFIG_JUMP_LABEL=y
-CONFIG_STRICT_KERNEL_RWX=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEBUG_FS is not set
# CONFIG_MQ_IOSCHED_DEADLINE is not set
@@ -140,10 +145,12 @@ CONFIG_ASPEED_BT_IPMI_BMC=y
CONFIG_HW_RANDOM_TIMERIOMEM=y
# CONFIG_I2C_COMPAT is not set
CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_MUX=y
CONFIG_I2C_MUX_PCA9541=y
CONFIG_I2C_MUX_PCA954x=y
CONFIG_I2C_ASPEED=y
CONFIG_I2C_FSI=y
+CONFIG_SPI=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_ASPEED=y
@@ -194,6 +201,10 @@ CONFIG_USB_CONFIGFS_F_LB_SS=y
CONFIG_USB_CONFIGFS_F_FS=y
CONFIG_USB_CONFIGFS_F_HID=y
CONFIG_USB_CONFIGFS_F_PRINTER=y
+CONFIG_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_SDHCI_OF_ASPEED=y
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
CONFIG_LEDS_CLASS_FLASH=y
--
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
* [PATCH 6/7] ARM: configs: multi_v7: Add ASPEED G6
From: Joel Stanley @ 2019-08-21 5:55 UTC (permalink / raw)
To: Rob Herring, Arnd Bergmann, Olof Johansson
Cc: Mark Rutland, devicetree, Ryan Chen, linux-aspeed, Andrew Jeffery,
Cédric Le Goater, linux-arm-kernel
In-Reply-To: <20190821055530.8720-1-joel@jms.id.au>
This adds the ASPEED AST2600 system and associated ASPEED devices so we
get build coverage.
The changes to the UART configuration to ensure the default console
(UART5) works.
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
arch/arm/configs/multi_v7_defconfig | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 3dc02a5e7672..ebb00321b1eb 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -9,6 +9,8 @@ CONFIG_ARCH_VIRT=y
CONFIG_ARCH_ALPINE=y
CONFIG_ARCH_ARTPEC=y
CONFIG_MACH_ARTPEC6=y
+CONFIG_ARCH_ASPEED=y
+CONFIG_MACH_ASPEED_G6=y
CONFIG_ARCH_AT91=y
CONFIG_SOC_SAMA5D2=y
CONFIG_SOC_SAMA5D3=y
@@ -200,6 +202,7 @@ CONFIG_MTD_NAND_VF610_NFC=y
CONFIG_MTD_NAND_DAVINCI=y
CONFIG_MTD_NAND_STM32_FMC2=y
CONFIG_MTD_SPI_NOR=y
+CONFIG_SPI_ASPEED_SMC=m
CONFIG_MTD_UBI=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
@@ -306,7 +309,11 @@ CONFIG_INPUT_STPMIC1_ONKEY=y
CONFIG_SERIO_AMBAKMI=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=5
+CONFIG_SERIAL_8250_RUNTIME_UARTS=5
CONFIG_SERIAL_8250_EXTENDED=y
+CONFIG_SERIAL_8250_MANY_PORTS=y
+CONFIG_SERIAL_8250_ASPEED_VUART=m
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_BCM2835AUX=y
CONFIG_SERIAL_8250_DW=y
@@ -351,6 +358,8 @@ CONFIG_SERIAL_STM32=y
CONFIG_SERIAL_STM32_CONSOLE=y
CONFIG_SERIAL_DEV_BUS=y
CONFIG_VIRTIO_CONSOLE=y
+CONFIG_ASPEED_KCS_IPMI_BMC=m
+CONFIG_ASPEED_BT_IPMI_BMC=m
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_ST=y
CONFIG_TCG_TPM=m
@@ -360,6 +369,7 @@ CONFIG_I2C_ARB_GPIO_CHALLENGE=m
CONFIG_I2C_MUX_PCA954x=y
CONFIG_I2C_MUX_PINCTRL=y
CONFIG_I2C_DEMUX_PINCTRL=y
+CONFIG_I2C_ASPEED=m
CONFIG_I2C_AT91=m
CONFIG_I2C_BCM2835=y
CONFIG_I2C_CADENCE=y
@@ -464,6 +474,7 @@ CONFIG_CHARGER_MAX77693=m
CONFIG_CHARGER_MAX8997=m
CONFIG_CHARGER_MAX8998=m
CONFIG_CHARGER_TPS65090=y
+CONFIG_SENSORS_ASPEED=m
CONFIG_SENSORS_IIO_HWMON=y
CONFIG_SENSORS_LM90=y
CONFIG_SENSORS_LM95245=y
@@ -594,6 +605,7 @@ CONFIG_VIDEO_V4L2_SUBDEV_API=y
CONFIG_MEDIA_USB_SUPPORT=y
CONFIG_USB_VIDEO_CLASS=m
CONFIG_V4L_PLATFORM_DRIVERS=y
+CONFIG_VIDEO_ASPEED=m
CONFIG_VIDEO_STM32_DCMI=m
CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS=m
CONFIG_VIDEO_S5P_FIMC=m
@@ -663,6 +675,7 @@ CONFIG_DRM_MXSFB=m
CONFIG_DRM_PL111=m
CONFIG_DRM_LIMA=m
CONFIG_DRM_PANFROST=m
+CONFIG_DRM_ASPEED_GFX=m
CONFIG_FB_EFI=y
CONFIG_FB_WM8505=y
CONFIG_FB_SH_MOBILE_LCDC=y
@@ -762,6 +775,7 @@ CONFIG_USB_MXS_PHY=y
CONFIG_USB_GADGET=y
CONFIG_USB_FSL_USB2=y
CONFIG_USB_RENESAS_USBHS_UDC=m
+CONFIG_USB_ASPEED_VHUB=m
CONFIG_USB_CONFIGFS=m
CONFIG_USB_CONFIGFS_SERIAL=y
CONFIG_USB_CONFIGFS_ACM=y
@@ -870,6 +884,7 @@ CONFIG_RTC_DRV_TEGRA=y
CONFIG_RTC_DRV_ST_LPC=y
CONFIG_RTC_DRV_STM32=y
CONFIG_RTC_DRV_CPCAP=m
+CONFIG_RTC_DRV_ASPEED=m
CONFIG_DMADEVICES=y
CONFIG_AT_HDMAC=y
CONFIG_AT_XDMAC=y
@@ -920,6 +935,9 @@ CONFIG_TEGRA_IOMMU_SMMU=y
CONFIG_REMOTEPROC=m
CONFIG_ST_REMOTEPROC=m
CONFIG_RPMSG_VIRTIO=m
+CONFIG_ASPEED_LPC_CTRL=m
+CONFIG_ASPEED_LPC_SNOOP=m
+CONFIG_ASPEED_P2A_CTRL=m
CONFIG_RASPBERRYPI_POWER=y
CONFIG_QCOM_GSBI=y
CONFIG_QCOM_PM=y
@@ -952,6 +970,7 @@ CONFIG_ARM_TEGRA_DEVFREQ=m
CONFIG_TI_AEMIF=y
CONFIG_IIO=y
CONFIG_IIO_SW_TRIGGER=y
+CONFIG_ASPEED_ADC=m
CONFIG_AT91_ADC=m
CONFIG_AT91_SAMA5D2_ADC=m
CONFIG_BERLIN2_ADC=m
--
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
* [PATCH 5/7] ARM: dts: aspeed: Add AST2600 and EVB
From: Joel Stanley @ 2019-08-21 5:55 UTC (permalink / raw)
To: Rob Herring, Arnd Bergmann, Olof Johansson
Cc: Mark Rutland, devicetree, Ryan Chen, linux-aspeed, Andrew Jeffery,
Cédric Le Goater, linux-arm-kernel
In-Reply-To: <20190821055530.8720-1-joel@jms.id.au>
The AST2600 is a new SoC by ASPEED. It contains a dual core Cortex A7
CPU and shares many periperhals with the existing AST2400 and AST2500.
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/aspeed-ast2600-evb.dts | 44 ++++
arch/arm/boot/dts/aspeed-g6.dtsi | 266 +++++++++++++++++++++++
3 files changed, 311 insertions(+)
create mode 100644 arch/arm/boot/dts/aspeed-ast2600-evb.dts
create mode 100644 arch/arm/boot/dts/aspeed-g6.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 247e556de48e..2d8d29e5686d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1276,6 +1276,7 @@ dtb-$(CONFIG_ARCH_MILBEAUT) += milbeaut-m10v-evb.dtb
dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-ast2500-evb.dtb \
+ aspeed-ast2600-evb.dtb \
aspeed-bmc-arm-centriq2400-rep.dtb \
aspeed-bmc-arm-stardragon4800-rep2.dtb \
aspeed-bmc-facebook-cmm.dtb \
diff --git a/arch/arm/boot/dts/aspeed-ast2600-evb.dts b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
new file mode 100644
index 000000000000..7f2528e084b5
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright 2019 IBM Corp.
+
+/dts-v1/;
+
+#include "aspeed-g6.dtsi"
+
+/ {
+ model = "AST2600 EVB";
+ compatible = "aspeed,ast2600";
+
+ aliases {
+ serial4 = &uart5;
+ };
+
+ chosen {
+ bootargs = "console=ttyS4,115200n8";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x80000000 0x80000000>;
+ };
+};
+
+&mdio1 {
+ status = "okay";
+
+ ethphy1: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+};
+
+&mac1 {
+ status = "okay";
+
+ phy-mode = "rgmii";
+ phy-handle = <ðphy1>;
+};
+
+&emmc {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
new file mode 100644
index 000000000000..9f9931541060
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed-g6.dtsi
@@ -0,0 +1,266 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+// Copyright 2019 IBM Corp.
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/ast2600-clock.h>
+
+/ {
+ model = "Aspeed BMC";
+ compatible = "aspeed,ast2600";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&gic>;
+
+ aliases {
+ serial4 = &uart5;
+ };
+
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ enable-method = "aspeed,ast2600-smp";
+
+ cpu@f00 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ reg = <0xf00>;
+ };
+
+ cpu@f01 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ reg = <0xf01>;
+ };
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
+ clocks = <&syscon ASPEED_CLK_HPLL>;
+ arm,cpu-registers-not-fw-configured;
+ };
+
+ ahb {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ ranges;
+
+ gic: interrupt-controller@40461000 {
+ compatible = "arm,cortex-a7-gic";
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ interrupt-parent = <&gic>;
+ reg = <0x40461000 0x1000>,
+ <0x40462000 0x1000>,
+ <0x40464000 0x2000>,
+ <0x40466000 0x2000>;
+ };
+
+ mdio0: mdio@1e650000 {
+ compatible = "aspeed,ast2600-mdio";
+ reg = <0x1e650000 0x8>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ mdio1: mdio@1e650008 {
+ compatible = "aspeed,ast2600-mdio";
+ reg = <0x1e650008 0x8>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ mdio2: mdio@1e650010 {
+ compatible = "aspeed,ast2600-mdio";
+ reg = <0x1e650010 0x8>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ mdio3: mdio@1e650018 {
+ compatible = "aspeed,ast2600-mdio";
+ reg = <0x1e650018 0x8>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ mac0: ftgmac@1e660000 {
+ compatible = "aspeed,ast2600-mac", "faraday,ftgmac100";
+ reg = <0x1e660000 0x180>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&syscon ASPEED_CLK_GATE_MAC1CLK>;
+ status = "disabled";
+ };
+
+ mac1: ftgmac@1e680000 {
+ compatible = "aspeed,ast2600-mac", "faraday,ftgmac100";
+ reg = <0x1e680000 0x180>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&syscon ASPEED_CLK_GATE_MAC2CLK>;
+ status = "disabled";
+ };
+
+ mac2: ftgmac@1e670000 {
+ compatible = "aspeed,ast2600-mac", "faraday,ftgmac100";
+ reg = <0x1e670000 0x180>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&syscon ASPEED_CLK_GATE_MAC3CLK>;
+ status = "disabled";
+ };
+
+ mac3: ftgmac@1e690000 {
+ compatible = "aspeed,ast2600-mac", "faraday,ftgmac100";
+ reg = <0x1e690000 0x180>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&syscon ASPEED_CLK_GATE_MAC4CLK>;
+ status = "disabled";
+ };
+
+ apb {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ syscon: syscon@1e6e2000 {
+ compatible = "aspeed,ast2600-scu", "syscon", "simple-mfd";
+ reg = <0x1e6e2000 0x1000>;
+ ranges = <0 0x1e6e2000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+
+ pinctrl: pinctrl {
+ compatible = "aspeed,ast2600-pinctrl";
+ };
+
+ smp-memram@180 {
+ compatible = "aspeed,ast2600-smpmem";
+ reg = <0x180 0x40>;
+ };
+ };
+
+ rng: hwrng@1e6e2524 {
+ compatible = "timeriomem_rng";
+ reg = <0x1e6e2524 0x4>;
+ period = <1>;
+ quality = <100>;
+ };
+
+ rtc: rtc@1e781000 {
+ compatible = "aspeed,ast2600-rtc";
+ reg = <0x1e781000 0x18>;
+ interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ uart5: serial@1e784000 {
+ compatible = "ns16550a";
+ reg = <0x1e784000 0x1000>;
+ reg-shift = <2>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&syscon ASPEED_CLK_GATE_UART5CLK>;
+ no-loopback-test;
+ };
+
+ wdt1: watchdog@1e785000 {
+ compatible = "aspeed,ast2600-wdt";
+ reg = <0x1e785000 0x40>;
+ };
+
+ wdt2: watchdog@1e785040 {
+ compatible = "aspeed,ast2600-wdt";
+ reg = <0x1e785040 0x40>;
+ status = "disabled";
+ };
+
+ wdt3: watchdog@1e785080 {
+ compatible = "aspeed,ast2600-wdt";
+ reg = <0x1e785080 0x40>;
+ status = "disabled";
+ };
+
+ wdt4: watchdog@1e7850C0 {
+ compatible = "aspeed,ast2600-wdt";
+ reg = <0x1e7850C0 0x40>;
+ status = "disabled";
+ };
+
+ sdc: sdc@1e740000 {
+ compatible = "aspeed,ast2600-sd-controller";
+ reg = <0x1e740000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x1e740000 0x10000>;
+ clocks = <&syscon ASPEED_CLK_GATE_SDCLK>;
+ status = "disabled";
+
+ sdhci0: sdhci@1e740100 {
+ compatible = "aspeed,ast2600-sdhci", "sdhci";
+ reg = <0x100 0x100>;
+ interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
+ sdhci,auto-cmd12;
+ clocks = <&syscon ASPEED_CLK_SDIO>;
+ status = "disabled";
+ };
+
+ sdhci1: sdhci@1e740200 {
+ compatible = "aspeed,ast2600-sdhci", "sdhci";
+ reg = <0x200 0x100>;
+ interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
+ sdhci,auto-cmd12;
+ clocks = <&syscon ASPEED_CLK_SDIO>;
+ status = "disabled";
+ };
+ };
+
+ emmc: sdc@1e750000 {
+ compatible = "aspeed,ast2600-sd-controller";
+ reg = <0x1e750000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x1e750000 0x10000>;
+ clocks = <&syscon ASPEED_CLK_GATE_EMMCCLK>;
+ status = "disabled";
+
+ sdhci@1e750100 {
+ compatible = "aspeed,ast2600-sdhci";
+ reg = <0x100 0x100>;
+ sdhci,auto-cmd12;
+ interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&syscon ASPEED_CLK_EMMC>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_emmc_default>;
+ };
+ };
+ };
+ };
+};
+
+&pinctrl {
+ pinctrl_emmc_default: emmc_default {
+ function = "SD3";
+ groups = "SD3";
+ };
+};
--
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
* [PATCH 4/7] ARM: aspeed: Enable SMP boot
From: Joel Stanley @ 2019-08-21 5:55 UTC (permalink / raw)
To: Rob Herring, Arnd Bergmann, Olof Johansson
Cc: Mark Rutland, devicetree, Ryan Chen, linux-aspeed, Andrew Jeffery,
Cédric Le Goater, linux-arm-kernel
In-Reply-To: <20190821055530.8720-1-joel@jms.id.au>
This brings the secondary CPU into Linux. It depends on the setup
performed by ASPEED's u-boot.
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
arch/arm/Makefile | 1 +
arch/arm/mach-aspeed/Makefile | 5 +++
arch/arm/mach-aspeed/platsmp.c | 61 ++++++++++++++++++++++++++++++++++
3 files changed, 67 insertions(+)
create mode 100644 arch/arm/mach-aspeed/Makefile
create mode 100644 arch/arm/mach-aspeed/platsmp.c
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index f96419135d35..be2fc3e79434 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -155,6 +155,7 @@ textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
machine-$(CONFIG_ARCH_ACTIONS) += actions
machine-$(CONFIG_ARCH_ALPINE) += alpine
machine-$(CONFIG_ARCH_ARTPEC) += artpec
+machine-$(CONFIG_ARCH_ASPEED) += aspeed
machine-$(CONFIG_ARCH_AT91) += at91
machine-$(CONFIG_ARCH_AXXIA) += axxia
machine-$(CONFIG_ARCH_BCM) += bcm
diff --git a/arch/arm/mach-aspeed/Makefile b/arch/arm/mach-aspeed/Makefile
new file mode 100644
index 000000000000..1951b3317a76
--- /dev/null
+++ b/arch/arm/mach-aspeed/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+# Copyright (C) ASPEED Technology Inc.
+# Copyright IBM Corp.
+
+obj-$(CONFIG_SMP) += platsmp.o
diff --git a/arch/arm/mach-aspeed/platsmp.c b/arch/arm/mach-aspeed/platsmp.c
new file mode 100644
index 000000000000..2324becf7991
--- /dev/null
+++ b/arch/arm/mach-aspeed/platsmp.c
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+// Copyright (C) ASPEED Technology Inc.
+// Copyright IBM Corp.
+
+#include <linux/of_address.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/smp.h>
+
+#define BOOT_ADDR 0x00
+#define BOOT_SIG 0x04
+
+static struct device_node *secboot_node;
+
+static int aspeed_g6_boot_secondary(unsigned int cpu, struct task_struct *idle)
+{
+ void __iomem *base;
+
+ base = of_iomap(secboot_node, 0);
+ if (!base) {
+ pr_err("could not map the secondary boot base!");
+ return -ENODEV;
+ }
+
+ writel_relaxed(0, base + BOOT_ADDR);
+ writel_relaxed(__pa_symbol(secondary_startup_arm), base + BOOT_ADDR);
+ writel_relaxed((0xABBAAB00 | (cpu & 0xff)), base + BOOT_SIG);
+
+ dsb_sev();
+
+ iounmap(base);
+
+ return 0;
+}
+
+static void __init aspeed_g6_smp_prepare_cpus(unsigned int max_cpus)
+{
+ void __iomem *base;
+
+ secboot_node = of_find_compatible_node(NULL, NULL, "aspeed,ast2600-smpmem");
+ if (!secboot_node) {
+ pr_err("secboot device node found!!\n");
+ return;
+ }
+
+ base = of_iomap(secboot_node, 0);
+ if (!base) {
+ pr_err("could not map the secondary boot base!");
+ return;
+ }
+ __raw_writel(0xBADABABA, base + BOOT_SIG);
+
+ iounmap(base);
+}
+
+static const struct smp_operations aspeed_smp_ops __initconst = {
+ .smp_prepare_cpus = aspeed_g6_smp_prepare_cpus,
+ .smp_boot_secondary = aspeed_g6_boot_secondary,
+};
+
+CPU_METHOD_OF_DECLARE(aspeed_smp, "aspeed,ast2600-smp", &aspeed_smp_ops);
--
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
* [PATCH 3/7] ARM: aspeed: Add ASPEED AST2600 architecture
From: Joel Stanley @ 2019-08-21 5:55 UTC (permalink / raw)
To: Rob Herring, Arnd Bergmann, Olof Johansson
Cc: Mark Rutland, devicetree, Ryan Chen, linux-aspeed, Andrew Jeffery,
Cédric Le Goater, linux-arm-kernel
In-Reply-To: <20190821055530.8720-1-joel@jms.id.au>
The AST2600 is a Cortex A7 dual core CPU that uses the ARM GIC for
interrupts and ARM timer as a clocksource.
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
arch/arm/mach-aspeed/Kconfig | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-aspeed/Kconfig b/arch/arm/mach-aspeed/Kconfig
index 2979aa4daeea..56007b0b6120 100644
--- a/arch/arm/mach-aspeed/Kconfig
+++ b/arch/arm/mach-aspeed/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
menuconfig ARCH_ASPEED
bool "Aspeed BMC architectures"
- depends on ARCH_MULTI_V5 || ARCH_MULTI_V6
+ depends on ARCH_MULTI_V5 || ARCH_MULTI_V6 || ARCH_MULTI_V7
select SRAM
select WATCHDOG
select ASPEED_WATCHDOG
@@ -33,4 +33,16 @@ config MACH_ASPEED_G5
Say yes if you intend to run on an Aspeed ast2500 or similar
fifth generation Aspeed BMCs.
+config MACH_ASPEED_G6
+ bool "Aspeed SoC 6th Generation"
+ depends on ARCH_MULTI_V7
+ select CPU_V7
+ select PINCTRL_ASPEED_G6
+ select ARM_GIC
+ select HAVE_ARM_ARCH_TIMER
+ select HAVE_SMP
+ help
+ Say yes if you intend to run on an Aspeed ast2600 or similar
+ sixth generation Aspeed BMCs.
+
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
* [PATCH 2/7] ARM: aspeed: Select timer in each SoC
From: Joel Stanley @ 2019-08-21 5:55 UTC (permalink / raw)
To: Rob Herring, Arnd Bergmann, Olof Johansson
Cc: Mark Rutland, devicetree, Ryan Chen, linux-aspeed, Andrew Jeffery,
Cédric Le Goater, linux-arm-kernel
In-Reply-To: <20190821055530.8720-1-joel@jms.id.au>
In preparation for adding the ast2600 which does not use this timer.
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
arch/arm/mach-aspeed/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-aspeed/Kconfig b/arch/arm/mach-aspeed/Kconfig
index a15c3a291386..2979aa4daeea 100644
--- a/arch/arm/mach-aspeed/Kconfig
+++ b/arch/arm/mach-aspeed/Kconfig
@@ -5,7 +5,6 @@ menuconfig ARCH_ASPEED
select SRAM
select WATCHDOG
select ASPEED_WATCHDOG
- select FTTMR010_TIMER
select MFD_SYSCON
select PINCTRL
help
@@ -18,6 +17,7 @@ config MACH_ASPEED_G4
depends on ARCH_MULTI_V5
select CPU_ARM926T
select PINCTRL_ASPEED_G4
+ select FTTMR010_TIMER
help
Say yes if you intend to run on an Aspeed ast2400 or similar
fourth generation BMCs, such as those used by OpenPower Power8
@@ -28,6 +28,7 @@ config MACH_ASPEED_G5
depends on ARCH_MULTI_V6
select CPU_V6
select PINCTRL_ASPEED_G5
+ select FTTMR010_TIMER
help
Say yes if you intend to run on an Aspeed ast2500 or similar
fifth generation Aspeed BMCs.
--
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
* [PATCH 1/7] dt-bindings: arm: cpus: Add ASPEED SMP
From: Joel Stanley @ 2019-08-21 5:55 UTC (permalink / raw)
To: Rob Herring, Arnd Bergmann, Olof Johansson
Cc: Mark Rutland, devicetree, Ryan Chen, linux-aspeed, Andrew Jeffery,
Cédric Le Goater, linux-arm-kernel
In-Reply-To: <20190821055530.8720-1-joel@jms.id.au>
The AST2600 SoC contains two CPUs and requires the operating system to
bring the second one out of firmware.
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
Documentation/devicetree/bindings/arm/cpus.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
index aa40b074b864..727e0ffc702b 100644
--- a/Documentation/devicetree/bindings/arm/cpus.yaml
+++ b/Documentation/devicetree/bindings/arm/cpus.yaml
@@ -175,6 +175,7 @@ properties:
- amlogic,meson8-smp
- amlogic,meson8b-smp
- arm,realview-smp
+ - aspeed,ast2600-smp
- brcm,bcm11351-cpu-method
- brcm,bcm23550
- brcm,bcm2836-smp
--
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
* [PATCH 0/7] ARM: Add ASPEED AST2600 support
From: Joel Stanley @ 2019-08-21 5:55 UTC (permalink / raw)
To: Rob Herring, Arnd Bergmann, Olof Johansson
Cc: Mark Rutland, devicetree, Ryan Chen, linux-aspeed, Andrew Jeffery,
Cédric Le Goater, linux-arm-kernel
Hello,
This adds the architecture, device tree and configuration required to
support a new ASPEED BMC chip.
I'd appreciate a review from those on cc before I break the patches into
their respective trees and send them as part of my ASPEED pull request
for 5.4. Thanks!
Joel Stanley (7):
dt-bindings: arm: cpus: Add ASPEED SMP
ARM: aspeed: Select timer in each SoC
ARM: aspeed: Add ASPEED AST2600 architecture
ARM: aspeed: Enable SMP boot
ARM: dts: aspeed: Add AST2600 and EVB
ARM: configs: multi_v7: Add ASPEED G6
ARM: configs: aspeed_g5: Enable AST2600
.../devicetree/bindings/arm/cpus.yaml | 1 +
arch/arm/Makefile | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/aspeed-ast2600-evb.dts | 44 +++
arch/arm/boot/dts/aspeed-g6.dtsi | 266 ++++++++++++++++++
arch/arm/configs/aspeed_g5_defconfig | 17 +-
arch/arm/configs/multi_v7_defconfig | 19 ++
arch/arm/mach-aspeed/Kconfig | 17 +-
arch/arm/mach-aspeed/Makefile | 5 +
arch/arm/mach-aspeed/platsmp.c | 61 ++++
10 files changed, 427 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/boot/dts/aspeed-ast2600-evb.dts
create mode 100644 arch/arm/boot/dts/aspeed-g6.dtsi
create mode 100644 arch/arm/mach-aspeed/Makefile
create mode 100644 arch/arm/mach-aspeed/platsmp.c
--
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
* Re: Build regression in Linux 5.3-rc5 with CONFIG_XEN=y
From: Stefan Wahren @ 2019-08-21 5:55 UTC (permalink / raw)
To: Stefan Wahren, Bjorn Andersson, Stephen Boyd
Cc: Avaneesh Kumar Dwivedi, iommu, Ian Jackson, Robin Murphy,
Christoph Hellwig, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <a69cce68-8c41-2030-b011-cdfacfeae421@gmx.net>
Hi Bjorn,
hi Stephen,
Am 20.08.19 um 07:43 schrieb Stefan Wahren:
> Hi Christoph,
>
> Am 20.08.19 um 03:24 schrieb Christoph Hellwig:
>> Hi Stefan,
>>
>> please try the patch below.
>>
>> ---
>> From e0570628d96faa50ebfc94ce8e545968336db225 Mon Sep 17 00:00:00 2001
>> From: Christoph Hellwig <hch@lst.de>
>> Date: Tue, 20 Aug 2019 10:08:38 +0900
>> Subject: arm: select the dma-noncoherent symbols for all swiotlb builds
>>
>> We need to provide the arch hooks for non-coherent dma-direct
>> and swiotlb for all swiotlb builds, not just when LPAS is enabled.
> s/LPAS/LPAE/
>> Without that the Xen build that selects SWIOTLB indirectly through
>> SWIOTLB_XEN fails to build.
>>
>> Fixes: ad3c7b18c5b3 ("arm: use swiotlb for bounce buffering on LPAE configs")
>> Reported-by: Stefan Wahren <wahrenst@gmx.net>
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
> i applied this patch and it fixes the build issue i reported before. But
> this seems to reveal another build issue in drivers/firmware/qcom_scm.c:
>
> drivers/firmware/qcom_scm.c: In function ‘qcom_scm_assign_mem’:
> drivers/firmware/qcom_scm.c:460:47: error: passing argument 3 of
> ‘dma_alloc_coherent’ from incompatible pointer type
> [-Werror=incompatible-pointer-types]
> ptr = dma_alloc_coherent(__scm->dev, ptr_sz, &ptr_phys, GFP_KERNEL);
> ^
> In file included from drivers/firmware/qcom_scm.c:12:0:
> ./include/linux/dma-mapping.h:636:21: note: expected ‘dma_addr_t * {aka
> long long unsigned int *}’ but argument is of type ‘phys_addr_t * {aka
> unsigned int *}’
> static inline void *dma_alloc_coherent(struct device *dev, size_t size,
> ^~~~~~~~~~~~~~~~~~
> cc1: some warnings being treated as errors
> scripts/Makefile.build:280: die Regel für Ziel
> „drivers/firmware/qcom_scm.o“ scheiterte
>
> Luckily there is already a patch to fix this in linux-next:
>
> firmware: qcom_scm: Use proper types for dma mappings
could you please take care that this patch is applied to 5.3-fixes?
>
> It seems that it misses the fixes tag.
>
> Regards
> Stefan
>
>
> _______________________________________________
> 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: [linux-sunxi] [PATCH v5 09/15] clk: sunxi-ng: h6: Allow I2S to change parent rate
From: Code Kipper @ 2019-08-21 5:52 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Jernej Skrabec, Linux-ALSA, linux-kernel, Liam Girdwood,
Andrea Venturi (pers), linux-sunxi, Mark Brown, Maxime Ripard,
linux-arm-kernel
In-Reply-To: <CAGb2v65+-OB4zEyW8f7hcWHkL7DtfEB1YK2B1nOKdgNdNqC0kQ@mail.gmail.com>
Thanks....I've added to my next patch series but if you could add it
when applying that would be great.
BR,
CK
On Wed, 21 Aug 2019 at 06:07, Chen-Yu Tsai <wens@csie.org> wrote:
>
> On Wed, Aug 14, 2019 at 2:09 PM <codekipper@gmail.com> wrote:
> >
> > From: Jernej Skrabec <jernej.skrabec@siol.net>
> >
> > I2S doesn't work if parent rate couldn't be change. Difference between
> > wanted and actual rate is too big.
> >
> > Fix this by adding CLK_SET_RATE_PARENT flag to I2S clocks.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>
> This lacks your SoB. Please reply and I can add it when applying.
>
> ChenYu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: dts: aspeed: swift: Add eMMC device
From: Joel Stanley @ 2019-08-21 4:56 UTC (permalink / raw)
To: Andrew Jeffery, Adriana Kobylak
Cc: devicetree, linux-aspeed, linux-arm-kernel
Swift contains an eMMC device attached to the second SDHCI controller.
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
arch/arm/boot/dts/aspeed-bmc-opp-swift.dts | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-swift.dts b/arch/arm/boot/dts/aspeed-bmc-opp-swift.dts
index f14f745b34ca..25bc0e1bbced 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-swift.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-swift.dts
@@ -963,4 +963,15 @@
status = "okay";
};
+&sdmmc {
+ status = "okay";
+};
+
+&sdhci1 {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sd2_default>;
+};
+
#include "ibm-power9-dual.dtsi"
--
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: [linux-sunxi] [PATCH v5 09/15] clk: sunxi-ng: h6: Allow I2S to change parent rate
From: Chen-Yu Tsai @ 2019-08-21 4:07 UTC (permalink / raw)
To: Code Kipper
Cc: Jernej Skrabec, Linux-ALSA, linux-kernel, Liam Girdwood,
Andrea Venturi (pers), linux-sunxi, Mark Brown, Maxime Ripard,
linux-arm-kernel
In-Reply-To: <20190814060854.26345-10-codekipper@gmail.com>
On Wed, Aug 14, 2019 at 2:09 PM <codekipper@gmail.com> wrote:
>
> From: Jernej Skrabec <jernej.skrabec@siol.net>
>
> I2S doesn't work if parent rate couldn't be change. Difference between
> wanted and actual rate is too big.
>
> Fix this by adding CLK_SET_RATE_PARENT flag to I2S clocks.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
This lacks your SoB. Please reply and I can add it when applying.
ChenYu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v13 12/12] arm64: dts: add gce node for mt8183
From: Bibby Hsieh @ 2019-08-20 8:36 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
Daoyuan Huang, Sascha Hauer, linux-kernel, Daniel Kurtz,
Dennis-YC Hsieh, linux-mediatek, Houlong Wei, Sascha Hauer,
YT Shen, Jiaguang Zhang, Bibby Hsieh, linux-arm-kernel,
ginny.chen
In-Reply-To: <20190820083635.5404-1-bibby.hsieh@mediatek.com>
add gce device node for mt8183
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 08274bfcebd8..a81c995bbea9 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -8,6 +8,7 @@
#include <dt-bindings/clock/mt8183-clk.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/gce/mt8183-gce.h>
/ {
compatible = "mediatek,mt8183";
@@ -212,6 +213,15 @@
clock-names = "spi", "wrap";
};
+ gce: mailbox@10238000 {
+ compatible = "mediatek,mt8183-gce";
+ reg = <0 0x10238000 0 0x4000>;
+ interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_LOW>;
+ #mbox-cells = <3>;
+ clocks = <&infracfg CLK_INFRA_GCE>;
+ clock-names = "gce";
+ };
+
uart0: serial@11002000 {
compatible = "mediatek,mt8183-uart",
"mediatek,mt6577-uart";
--
2.18.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 v13 12/12] arm64: dts: add gce node for mt8183
From: Bibby Hsieh @ 2019-08-20 8:49 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
Daoyuan Huang, Sascha Hauer, linux-kernel, Daniel Kurtz,
Dennis-YC Hsieh, linux-mediatek, Houlong Wei, Sascha Hauer,
YT Shen, Jiaguang Zhang, Bibby Hsieh, linux-arm-kernel,
ginny.chen
In-Reply-To: <20190820084932.22282-1-bibby.hsieh@mediatek.com>
add gce device node for mt8183
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 08274bfcebd8..a81c995bbea9 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -8,6 +8,7 @@
#include <dt-bindings/clock/mt8183-clk.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/gce/mt8183-gce.h>
/ {
compatible = "mediatek,mt8183";
@@ -212,6 +213,15 @@
clock-names = "spi", "wrap";
};
+ gce: mailbox@10238000 {
+ compatible = "mediatek,mt8183-gce";
+ reg = <0 0x10238000 0 0x4000>;
+ interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_LOW>;
+ #mbox-cells = <3>;
+ clocks = <&infracfg CLK_INFRA_GCE>;
+ clock-names = "gce";
+ };
+
uart0: serial@11002000 {
compatible = "mediatek,mt8183-uart",
"mediatek,mt6577-uart";
--
2.18.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
* [PATCH v13 11/12] soc: mediatek: cmdq: add cmdq_dev_get_client_reg function
From: Bibby Hsieh @ 2019-08-20 8:36 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
Daoyuan Huang, Sascha Hauer, linux-kernel, Daniel Kurtz,
Dennis-YC Hsieh, linux-mediatek, Houlong Wei, Sascha Hauer,
YT Shen, Jiaguang Zhang, Bibby Hsieh, linux-arm-kernel,
ginny.chen
In-Reply-To: <20190820083635.5404-1-bibby.hsieh@mediatek.com>
GCE cannot know the register base address, this function
can help cmdq client to get the cmdq_client_reg structure.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 29 ++++++++++++++++++++++++++
include/linux/soc/mediatek/mtk-cmdq.h | 21 +++++++++++++++++++
2 files changed, 50 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index fbccdcfc7b52..93cd9a9f9796 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -27,6 +27,35 @@ struct cmdq_instruction {
u8 op;
};
+int cmdq_dev_get_client_reg(struct device *dev,
+ struct cmdq_client_reg *client_reg, int idx)
+{
+ struct of_phandle_args spec;
+ int err;
+
+ if (!client_reg)
+ return -ENOENT;
+
+ err = of_parse_phandle_with_fixed_args(dev->of_node,
+ "mediatek,gce-client-reg",
+ 3, idx, &spec);
+ if (err < 0) {
+ dev_err(dev,
+ "error %d can't parse gce-client-reg property (%d)",
+ err, idx);
+
+ return err;
+ }
+
+ client_reg->subsys = (u8)spec.args[0];
+ client_reg->offset = (u16)spec.args[1];
+ client_reg->size = (u16)spec.args[2];
+ of_node_put(spec.np);
+
+ return 0;
+}
+EXPORT_SYMBOL(cmdq_dev_get_client_reg);
+
static void cmdq_client_timeout(struct timer_list *t)
{
struct cmdq_client *client = from_timer(client, t, timer);
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index a345870a6d10..02ddd60b212f 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -15,6 +15,12 @@
struct cmdq_pkt;
+struct cmdq_client_reg {
+ u8 subsys;
+ u16 offset;
+ u16 size;
+};
+
struct cmdq_client {
spinlock_t lock;
u32 pkt_cnt;
@@ -24,6 +30,21 @@ struct cmdq_client {
u32 timeout_ms; /* in unit of microsecond */
};
+/**
+ * cmdq_dev_get_client_reg() - parse cmdq client reg from the device
+ * node of CMDQ client
+ * @dev: device of CMDQ mailbox client
+ * @client_reg: CMDQ client reg pointer
+ * @idx: the index of desired reg
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ * Help CMDQ client parsing the cmdq client reg
+ * from the device node of CMDQ client.
+ */
+int cmdq_dev_get_client_reg(struct device *dev,
+ struct cmdq_client_reg *client_reg, int idx);
+
/**
* cmdq_mbox_create() - create CMDQ mailbox client and channel
* @dev: device of CMDQ mailbox client
--
2.18.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
* Re: [PATCH v13 09/12] soc: mediatek: cmdq: define the instruction struct
From: CK Hu @ 2019-08-20 8:42 UTC (permalink / raw)
To: Bibby Hsieh
Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
Daoyuan Huang, Sascha Hauer, Jassi Brar, linux-kernel,
Daniel Kurtz, Dennis-YC Hsieh, YT Shen, Rob Herring,
linux-mediatek, Houlong Wei, Sascha Hauer, Matthias Brugger,
Jiaguang Zhang, linux-arm-kernel, ginny.chen
In-Reply-To: <20190820083635.5404-10-bibby.hsieh@mediatek.com>
Hi, Bibby:
On Tue, 2019-08-20 at 16:36 +0800, Bibby Hsieh wrote:
> Define an instruction structure for gce driver to append command.
> This structure can make the client's code more readability.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> Reviewed-by: CK Hu <ck.hu@mediatek.com>
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 106 +++++++++++++++--------
> include/linux/mailbox/mtk-cmdq-mailbox.h | 2 +
> 2 files changed, 74 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 7aa0517ff2f3..cae6a794cc48 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -9,12 +9,24 @@
> #include <linux/mailbox_controller.h>
> #include <linux/soc/mediatek/mtk-cmdq.h>
>
> -#define CMDQ_ARG_A_WRITE_MASK 0xffff
> #define CMDQ_WRITE_ENABLE_MASK BIT(0)
> #define CMDQ_EOC_IRQ_EN BIT(0)
> #define CMDQ_EOC_CMD ((u64)((CMDQ_CODE_EOC << CMDQ_OP_CODE_SHIFT)) \
> << 32 | CMDQ_EOC_IRQ_EN)
>
> +struct cmdq_instruction {
> + union {
> + u32 value;
> + u32 mask;
> + };
> + union {
> + u16 offset;
> + u16 event;
> + };
> + u8 subsys;
> + u8 op;
> +};
> +
> static void cmdq_client_timeout(struct timer_list *t)
> {
> struct cmdq_client *client = from_timer(client, t, timer);
> @@ -110,10 +122,8 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt)
> }
> EXPORT_SYMBOL(cmdq_pkt_destroy);
>
> -static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
> - u32 arg_a, u32 arg_b)
> +static struct cmdq_instruction *cmdq_pkt_append_command(struct cmdq_pkt *pkt)
> {
> - u64 *cmd_ptr;
>
> if (unlikely(pkt->cmd_buf_size + CMDQ_INST_SIZE > pkt->buf_size)) {
> /*
> @@ -127,81 +137,109 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
> pkt->cmd_buf_size += CMDQ_INST_SIZE;
> WARN_ONCE(1, "%s: buffer size %u is too small !\n",
> __func__, (u32)pkt->buf_size);
> - return -ENOMEM;
> + return NULL;
> }
> - cmd_ptr = pkt->va_base + pkt->cmd_buf_size;
> - (*cmd_ptr) = (u64)((code << CMDQ_OP_CODE_SHIFT) | arg_a) << 32 | arg_b;
> +
> pkt->cmd_buf_size += CMDQ_INST_SIZE;
> + *(u64 *)(pkt->va_base + pkt->cmd_buf_size) = 0;
I think this statement should before 'pkt->cmd_buf_size +=
CMDQ_INST_SIZE;'
Regards,
CK
>
> - return 0;
> + return pkt->va_base + pkt->cmd_buf_size - CMDQ_INST_SIZE;
> }
>
> int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value)
> {
> - u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
> - (subsys << CMDQ_SUBSYS_SHIFT);
> + struct cmdq_instruction *inst;
> +
> + inst = cmdq_pkt_append_command(pkt);
> + if (!inst)
> + return -ENOMEM;
> +
> + inst->op = CMDQ_CODE_WRITE;
> + inst->value = value;
> + inst->offset = offset;
> + inst->subsys = subsys;
>
> - return cmdq_pkt_append_command(pkt, CMDQ_CODE_WRITE, arg_a, value);
> + return 0;
> }
> EXPORT_SYMBOL(cmdq_pkt_write);
>
> int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
> u16 offset, u32 value, u32 mask)
> {
> - u32 offset_mask = offset;
> - int err = 0;
> + struct cmdq_instruction *inst;
> + u16 offset_mask = offset;
>
> if (mask != 0xffffffff) {
> - err = cmdq_pkt_append_command(pkt, CMDQ_CODE_MASK, 0, ~mask);
> + inst = cmdq_pkt_append_command(pkt);
> + if (!inst)
> + return -ENOMEM;
> +
> + inst->op = CMDQ_CODE_MASK;
> + inst->mask = ~mask;
> offset_mask |= CMDQ_WRITE_ENABLE_MASK;
> }
> - err |= cmdq_pkt_write(pkt, value, subsys, offset_mask);
>
> - return err;
> + return cmdq_pkt_write(pkt, subsys, offset_mask, value);
> }
> EXPORT_SYMBOL(cmdq_pkt_write_mask);
>
> int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> {
> - u32 arg_b;
> + struct cmdq_instruction *inst;
>
> if (event >= CMDQ_MAX_EVENT)
> return -EINVAL;
>
> - /*
> - * WFE arg_b
> - * bit 0-11: wait value
> - * bit 15: 1 - wait, 0 - no wait
> - * bit 16-27: update value
> - * bit 31: 1 - update, 0 - no update
> - */
> - arg_b = CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | CMDQ_WFE_WAIT_VALUE;
> + inst = cmdq_pkt_append_command(pkt);
> + if (!inst)
> + return -ENOMEM;
> +
> + inst->op = CMDQ_CODE_WFE;
> + inst->value = CMDQ_WFE_OPTION;
> + inst->event = event;
>
> - return cmdq_pkt_append_command(pkt, CMDQ_CODE_WFE, event, arg_b);
> + return 0;
> }
> EXPORT_SYMBOL(cmdq_pkt_wfe);
>
> int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
> {
> + struct cmdq_instruction *inst;
> +
> if (event >= CMDQ_MAX_EVENT)
> return -EINVAL;
>
> - return cmdq_pkt_append_command(pkt, CMDQ_CODE_WFE, event,
> - CMDQ_WFE_UPDATE);
> + inst = cmdq_pkt_append_command(pkt);
> + if (!inst)
> + return -ENOMEM;
> +
> + inst->op = CMDQ_CODE_WFE;
> + inst->value = CMDQ_WFE_UPDATE;
> + inst->event = event;
> +
> + return 0;
> }
> EXPORT_SYMBOL(cmdq_pkt_clear_event);
>
> static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> {
> - int err;
> + struct cmdq_instruction *inst;
> +
> + inst = cmdq_pkt_append_command(pkt);
> + if (!inst)
> + return -ENOMEM;
>
> - /* insert EOC and generate IRQ for each command iteration */
> - err = cmdq_pkt_append_command(pkt, CMDQ_CODE_EOC, 0, CMDQ_EOC_IRQ_EN);
> + inst->op = CMDQ_CODE_EOC;
> + inst->value = CMDQ_EOC_IRQ_EN;
>
> - /* JUMP to end */
> - err |= cmdq_pkt_append_command(pkt, CMDQ_CODE_JUMP, 0, CMDQ_JUMP_PASS);
> + inst = cmdq_pkt_append_command(pkt);
> + if (!inst)
> + return -ENOMEM;
> +
> + inst->op = CMDQ_CODE_JUMP;
> + inst->value = CMDQ_JUMP_PASS;
>
> - return err;
> + return 0;
> }
>
> static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data data)
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index 911475da7a53..c8adedefaf42 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -19,6 +19,8 @@
> #define CMDQ_WFE_UPDATE BIT(31)
> #define CMDQ_WFE_WAIT BIT(15)
> #define CMDQ_WFE_WAIT_VALUE 0x1
> +#define CMDQ_WFE_OPTION (CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | \
> + CMDQ_WFE_WAIT_VALUE)
> /** cmdq event maximum */
> #define CMDQ_MAX_EVENT 0x3ff
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v13 07/12] soc: mediatek: cmdq: reorder the parameter
From: Bibby Hsieh @ 2019-08-20 8:36 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
Daoyuan Huang, Sascha Hauer, linux-kernel, Daniel Kurtz,
Dennis-YC Hsieh, linux-mediatek, Houlong Wei, Sascha Hauer,
YT Shen, Jiaguang Zhang, Bibby Hsieh, linux-arm-kernel,
ginny.chen
In-Reply-To: <20190820083635.5404-1-bibby.hsieh@mediatek.com>
The order of gce instructions is [subsys offset value]
so reorder the parameter of cmdq_pkt_write_mask
and cmdq_pkt_write function.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 6 +++---
include/linux/soc/mediatek/mtk-cmdq.h | 10 +++++-----
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index ff9fef5a032b..082b8978651e 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -136,7 +136,7 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
return 0;
}
-int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 value, u32 subsys, u32 offset)
+int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value)
{
u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
(subsys << CMDQ_SUBSYS_SHIFT);
@@ -145,8 +145,8 @@ int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 value, u32 subsys, u32 offset)
}
EXPORT_SYMBOL(cmdq_pkt_write);
-int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 value,
- u32 subsys, u32 offset, u32 mask)
+int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
+ u32 offset, u32 value, u32 mask)
{
u32 offset_mask = offset;
int err = 0;
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index 4e8899972db4..39d813dde4b4 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -60,26 +60,26 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt);
/**
* cmdq_pkt_write() - append write command to the CMDQ packet
* @pkt: the CMDQ packet
- * @value: the specified target register value
* @subsys: the CMDQ sub system code
* @offset: register offset from CMDQ sub system
+ * @value: the specified target register value
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 value, u32 subsys, u32 offset);
+int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value);
/**
* cmdq_pkt_write_mask() - append write command with mask to the CMDQ packet
* @pkt: the CMDQ packet
- * @value: the specified target register value
* @subsys: the CMDQ sub system code
* @offset: register offset from CMDQ sub system
+ * @value: the specified target register value
* @mask: the specified target register mask
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 value,
- u32 subsys, u32 offset, u32 mask);
+int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
+ u32 offset, u32 value, u32 mask);
/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
--
2.18.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
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