* [PATCH 0/3] KVM/Hyper-V: Add Hyper-V direct tlb flush support
From: lantianyu1986 @ 2019-08-09 9:49 UTC (permalink / raw)
To: pbonzini, rkrcmar, corbet, kys, haiyangz, sthemmin, sashal, tglx,
mingo, bp, hpa, x86, michael.h.kelley
Cc: Tianyu Lan, kvm, linux-doc, linux-hyperv, linux-kernel, vkuznets
From: Tianyu Lan <Tianyu.Lan@microsoft.com>
This patchset is to add Hyper-V direct tlb support in KVM. Hyper-V
in L0 can delegate L1 hypervisor to handle tlb flush request from
L2 guest when direct tlb flush is enabled in L1.
Patch 2 introduces new cap KVM_CAP_HYPERV_DIRECT_TLBFLUSH to enable
feature from user space. User space should enable this feature only
when Hyper-V hypervisor capability is exposed to guest and KVM profile
is hided. There is a parameter conflict between KVM and Hyper-V hypercall.
We hope L2 guest doesn't use KVM hypercall when the feature is
enabled. Detail please see comment of new API "KVM_CAP_HYPERV_DIRECT_TLBFLUSH"
Tianyu Lan (2):
x86/Hyper-V: Fix definition of struct hv_vp_assist_page
KVM/Hyper-V: Add new KVM cap KVM_CAP_HYPERV_DIRECT_TLBFLUSH
Vitaly Kuznetsov (1):
KVM/Hyper-V/VMX: Add direct tlb flush support
Documentation/virtual/kvm/api.txt | 10 ++++++++++
arch/x86/include/asm/hyperv-tlfs.h | 24 +++++++++++++++++++-----
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/vmx/evmcs.h | 2 ++
arch/x86/kvm/vmx/vmx.c | 38 ++++++++++++++++++++++++++++++++++++++
arch/x86/kvm/x86.c | 8 ++++++++
include/linux/kvm_host.h | 1 +
include/uapi/linux/kvm.h | 1 +
8 files changed, 81 insertions(+), 5 deletions(-)
--
2.14.2
^ permalink raw reply
* Re: [PATCH 5/6] tty: serial: Add linflexuart driver for S32V234
From: Stefan-gabriel Mirea @ 2019-08-09 9:45 UTC (permalink / raw)
To: Will Deacon
Cc: corbet@lwn.net, robh+dt@kernel.org, mark.rutland@arm.com,
gregkh@linuxfoundation.org, catalin.marinas@arm.com,
shawnguo@kernel.org, Leo Li, jslaby@suse.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-serial@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Cosmin Stefan Stoica,
Larisa Ileana Grigore
In-Reply-To: <20190808171711.nk7ljqkugtketu4q@willie-the-truck>
On 8/8/2019 8:17 PM, Will Deacon wrote:
> On Thu, Aug 08, 2019 at 12:47:00PM +0000, Stefan-gabriel Mirea wrote:
>> On 8/8/2019 11:08 AM, Will Deacon wrote:
>>> On Fri, Aug 02, 2019 at 07:47:23PM +0000, Stefan-gabriel Mirea wrote:
>>>> + linflex,<addr>
>>>> + Use early console provided by Freescale LinFlex UART
>>>> + serial driver for NXP S32V234 SoCs. A valid base
>>>> + address must be provided, and the serial port must
>>>> + already be setup and configured.
>>>
>>> Why isn't earlycon= sufficient for this?
>>
>> "earlycon=" is not actually supported. I will fix this in the next
>> version by adding a /chosen/stdout-path to the dts. The compatible
>> string provided to OF_EARLYCON_DECLARE will also be changed from
>> "fsl,s32v234-linflexuart" to "fsl,s32-linflexuart" to match the one in
>> the device tree nodes. I missed this after importing a rename from our
>> codebase.
>>
>> Should I remove this addition from kernel-parameters.txt after that?
>
> Yes, if you can use earlycon instead, then you can drop your custom option
> entirely and therefore there's no need to document it either.
Can you please clarify what you mean by "drop your custom option"? The
"linflex" option documented in the paragraph is the name of the
earlycon_id declared via "OF_EARLYCON_DECLARE(linflex, ...)". We have
not done anything particular to accept it in the parameter value.
We do use earlycon (e.g. "earlycon=linflex,0x40053000"), we just do not
support an empty value after "=", which needs to be fixed as I
understand, because it does not respect the comment[1] about ARM64.
Regards,
Stefan
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/kernel-parameters.txt?h=v5.3-rc3#n980
^ permalink raw reply
* Re: [Tee-dev] [RFC v2 2/6] tee: enable support to register kernel memory
From: Sumit Garg @ 2019-08-09 5:36 UTC (permalink / raw)
To: Stuart Yoder
Cc: keyrings, linux-integrity, linux-security-module,
tee-dev @ lists . linaro . org, Daniel Thompson, Jonathan Corbet,
jejb, Ard Biesheuvel, Linux Doc Mailing List, Mimi Zohar,
Linux Kernel Mailing List, dhowells, Jarkko Sakkinen,
Casey Schaufler, linux-arm-kernel, Serge E. Hallyn
In-Reply-To: <99777010-db74-096a-ce1a-da30539d6fb5@arm.com>
On Fri, 9 Aug 2019 at 03:57, Stuart Yoder <stuart.yoder@arm.com> wrote:
>
>
>
> On 7/30/19 7:23 AM, Sumit Garg wrote:
>
> > @@ -264,7 +266,17 @@ struct tee_shm *tee_shm_register(struct tee_context *ctx, unsigned long addr,
> > goto err;
> > }
> >
> > - rc = get_user_pages_fast(start, num_pages, FOLL_WRITE, shm->pages);
> > + if (flags & TEE_SHM_USER_MAPPED) {
> > + rc = get_user_pages_fast(start, num_pages, FOLL_WRITE,
> > + shm->pages);
> > + } else {
> > + const struct kvec kiov = {
> > + .iov_base = (void *)start,
> > + .iov_len = PAGE_SIZE
> > + };
> > +
> > + rc = get_kernel_pages(&kiov, num_pages, 0, shm->pages);
>
> Passing a single kvec struct is temporary I assume? Because as currently
> written this will only work with num_pages==1.
>
Ah, thanks Stuart for pointing this out. It should rather be an array
of kvec struct. Will fix it in next version.
-Sumit
> Stuart
^ permalink raw reply
* [PATCH 1/1] kbuild: recursive build of external kernel modules
From: Shaun Tancheff @ 2019-08-09 0:21 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Shaun Tancheff, linux-kbuild, Joe Lawrence,
'James E . J . Bottomley', Jonathan Corbet,
'Martin K . Petersen', Michal Marek, Shuah Khan,
Thomas Renninger, linux-doc, linux-kernel, linux-pm, linux-scsi
In-Reply-To: <20190809002104.18599-1-stancheff@cray.com>
When building a tree of external modules stage 2 fails
silently as the root modules.order is empty.
Modify the modules.order location to be fixed to the
root when KBUILD_EXTMOD is specified and write all
module paths to the single modules.order file.
Signed-off-by: Shaun Tancheff <stancheff@cray.com>
---
Makefile | 1 +
scripts/Makefile.build | 8 +++++++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 23cdf1f41364..a9964492f47e 100644
--- a/Makefile
+++ b/Makefile
@@ -1622,6 +1622,7 @@ $(module-dirs): prepare $(objtree)/Module.symvers
modules: $(module-dirs)
@$(kecho) ' Building modules, stage 2.';
+ $(Q)$rm -f $(KBUILD_EXTMOD)/modules.order
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
PHONY += modules_install
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 0d434d0afc0b..f9908b3d59e0 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -64,7 +64,13 @@ builtin-target := $(obj)/built-in.a
endif
ifeq ($(CONFIG_MODULES)$(need-modorder),y1)
+ifneq ($(KBUILD_EXTMOD),)
+modorder-target := $(KBUILD_EXTMOD)/modules.order
+modorder-add := >>
+else
modorder-target := $(obj)/modules.order
+modorder-add := >
+endif
endif
mod-targets := $(patsubst %.o, %.mod, $(obj-m))
@@ -423,7 +429,7 @@ endif # builtin-target
$(modorder-target): $(subdir-ym) FORCE
$(Q){ $(foreach m, $(modorder), \
$(if $(filter %/modules.order, $m), cat $m, echo $m);) :; } \
- | $(AWK) '!x[$$0]++' - > $@
+ | $(AWK) '!x[$$0]++' - $(modorder-add) $@
#
# Rule to compile a set of .o files into one .a file (with symbol table)
--
2.20.1
^ permalink raw reply related
* [PATCH 0/1] kbuild: Support building a tree of modules with -M=<root>
From: Shaun Tancheff @ 2019-08-09 0:21 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Shaun Tancheff, linux-kbuild, Joe Lawrence,
'James E . J . Bottomley', Jonathan Corbet,
'Martin K . Petersen', Michal Marek, Shuah Khan,
Thomas Renninger, linux-doc, linux-kernel, linux-pm, linux-scsi
Currently when building lustre against 5.3 kernel modules fail to
generate <module>.ko files.
Lustre builds a tree of modules however the numerous modules.order files
are created but only the modules.order file at the root appears to be
read.
This changes the the scheme for KBUILD_EXTMOD to write to and read from
a single modules.order file at the root.
Shaun Tancheff (1):
kbuild: recursive build of external kernel modules
Makefile | 1 +
scripts/Makefile.build | 8 +++++++-
2 files changed, 8 insertions(+), 1 deletion(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH v15 00/13] TCU patchset v15
From: Paul Burton @ 2019-08-08 23:02 UTC (permalink / raw)
To: Paul Cercueil
Cc: Ralf Baechle, Paul Burton, James Hogan, Jonathan Corbet,
Lee Jones, Arnd Bergmann, Daniel Lezcano, Thomas Gleixner,
Michael Turquette, Stephen Boyd, Jason Cooper, Marc Zyngier,
Rob Herring, Mark Rutland, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-mips@vger.kernel.org, linux-clk@vger.kernel.org, od@zcrc.me,
Mathieu Malaterre, linux-mips@vger.kernel.org
In-Reply-To: <20190724171615.20774-1-paul@crapouillou.net>
Hello,
Paul Cercueil wrote:
> Hi,
>
> This is the V15 of my Ingenic TCU patchet.
>
> The big change since V14 is that the custom MFD driver
> (ex patch 04/13) was dropped in favor of a small patch to syscon
> and a "simple-mfd" compatible.
>
> The patchset was based on mips/mips-next, but all of them minus
> the last one will apply cleanly on v5.3-rc1.
>
> Changelog:
>
> * [02/13]: Remove info about MFD driver
> * [03/13]: Add "simple-mfd" compatible string
> * [04/13]: New patch
> * [05/13]: - Use CLK_OF_DECLARE_DRIVER since we use "simple-mfd"
> - Use device_node_to_regmap()
> * [06/13]: Use device_node_to_regmap()
> * [07/13]: Use device_node_to_regmap()
> * [09/13]: Add "simple-mfd" compatible string
>
> Cheers,
Series applied to mips-next.
> dt-bindings: ingenic: Add DT bindings for TCU clocks
> commit 4bc3c420246e
> https://git.kernel.org/mips/c/4bc3c420246e
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> Tested-by: Mathieu Malaterre <malat@debian.org>
> Tested-by: Artur Rojek <contact@artur-rojek.eu>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Acked-by: Stephen Boyd <sboyd@kernel.org>
> Signed-off-by: Paul Burton <paul.burton@mips.com>
>
> doc: Add doc for the Ingenic TCU hardware
> commit 97689a1a3fda
> https://git.kernel.org/mips/c/97689a1a3fda
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> Tested-by: Mathieu Malaterre <malat@debian.org>
> Tested-by: Artur Rojek <contact@artur-rojek.eu>
> Signed-off-by: Paul Burton <paul.burton@mips.com>
>
> dt-bindings: Add doc for the Ingenic TCU drivers
> commit 2e8722a5255e
> https://git.kernel.org/mips/c/2e8722a5255e
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Tested-by: Mathieu Malaterre <malat@debian.org>
> Tested-by: Artur Rojek <contact@artur-rojek.eu>
> Signed-off-by: Paul Burton <paul.burton@mips.com>
>
> mfd/syscon: Add device_node_to_regmap()
> commit 39233b7c6112
> https://git.kernel.org/mips/c/39233b7c6112
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Paul Burton <paul.burton@mips.com>
>
> clk: ingenic: Add driver for the TCU clocks
> commit 4f89e4b8f121
> https://git.kernel.org/mips/c/4f89e4b8f121
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> Tested-by: Mathieu Malaterre <malat@debian.org>
> Tested-by: Artur Rojek <contact@artur-rojek.eu>
> Acked-by: Stephen Boyd <sboyd@kernel.org>
> Signed-off-by: Paul Burton <paul.burton@mips.com>
>
> irqchip: Add irq-ingenic-tcu driver
> commit 9536eba03ec7
> https://git.kernel.org/mips/c/9536eba03ec7
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> Tested-by: Mathieu Malaterre <malat@debian.org>
> Tested-by: Artur Rojek <contact@artur-rojek.eu>
> Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
> Acked-by: Marc Zyngier <maz@kernel.org>
> Signed-off-by: Paul Burton <paul.burton@mips.com>
>
> clocksource: Add a new timer-ingenic driver
> commit 34e9368301d5
> https://git.kernel.org/mips/c/34e9368301d5
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> Tested-by: Mathieu Malaterre <malat@debian.org>
> Tested-by: Artur Rojek <contact@artur-rojek.eu>
> Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Paul Burton <paul.burton@mips.com>
>
> clk: jz4740: Add TCU clock
> commit 73dd11dc1a88
> https://git.kernel.org/mips/c/73dd11dc1a88
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> Tested-by: Mathieu Malaterre <malat@debian.org>
> Tested-by: Artur Rojek <contact@artur-rojek.eu>
> Acked-by: Stephen Boyd <sboyd@kernel.org>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Paul Burton <paul.burton@mips.com>
>
> MIPS: jz4740: Add DTS nodes for the TCU drivers
> commit 36aafdbd5288
> https://git.kernel.org/mips/c/36aafdbd5288
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> Tested-by: Mathieu Malaterre <malat@debian.org>
> Tested-by: Artur Rojek <contact@artur-rojek.eu>
> Signed-off-by: Paul Burton <paul.burton@mips.com>
>
> MIPS: qi_lb60: Reduce system timer and clocksource to 750 kHz
> commit a68d3b052b57
> https://git.kernel.org/mips/c/a68d3b052b57
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> Tested-by: Mathieu Malaterre <malat@debian.org>
> Tested-by: Artur Rojek <contact@artur-rojek.eu>
> Signed-off-by: Paul Burton <paul.burton@mips.com>
>
> MIPS: CI20: Reduce system timer and clocksource to 3 MHz
> commit 157c887aff52
> https://git.kernel.org/mips/c/157c887aff52
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> Tested-by: Mathieu Malaterre <malat@debian.org>
> Tested-by: Artur Rojek <contact@artur-rojek.eu>
> Signed-off-by: Paul Burton <paul.burton@mips.com>
>
> MIPS: GCW0: Reduce system timer and clocksource to 750 kHz
> commit 967a7100400a
> https://git.kernel.org/mips/c/967a7100400a
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> Tested-by: Mathieu Malaterre <malat@debian.org>
> Tested-by: Artur Rojek <contact@artur-rojek.eu>
> Signed-off-by: Paul Burton <paul.burton@mips.com>
>
> MIPS: jz4740: Drop obsolete code
> commit abc552284f6b
> https://git.kernel.org/mips/c/abc552284f6b
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> Tested-by: Mathieu Malaterre <malat@debian.org>
> Tested-by: Artur Rojek <contact@artur-rojek.eu>
> Signed-off-by: Paul Burton <paul.burton@mips.com>
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorrect
then please email paul.burton@mips.com to report it. ]
^ permalink raw reply
* Business Proposal !!!
From: Mrs. Laura Cha Shih @ 2019-08-08 22:42 UTC (permalink / raw)
Greetings to you,I am Mrs. Laura Cha Shih, from Shanghai Banking Corporation Limited,(China). I have a business proposal worth USD$30,000,000 (Thirty Million United States Dollars Only) for you to transact with me. Reply For More Details.Best Regards
Mrs. Laura Cha Shih
^ permalink raw reply
* Re: [Tee-dev] [RFC v2 2/6] tee: enable support to register kernel memory
From: Stuart Yoder @ 2019-08-08 22:26 UTC (permalink / raw)
To: Sumit Garg, keyrings, linux-integrity, linux-security-module
Cc: tee-dev, daniel.thompson, corbet, jejb, ard.biesheuvel, linux-doc,
zohar, linux-kernel, dhowells, jarkko.sakkinen, casey,
linux-arm-kernel, serge
In-Reply-To: <1564489420-677-3-git-send-email-sumit.garg@linaro.org>
On 7/30/19 7:23 AM, Sumit Garg wrote:
> @@ -264,7 +266,17 @@ struct tee_shm *tee_shm_register(struct tee_context *ctx, unsigned long addr,
> goto err;
> }
>
> - rc = get_user_pages_fast(start, num_pages, FOLL_WRITE, shm->pages);
> + if (flags & TEE_SHM_USER_MAPPED) {
> + rc = get_user_pages_fast(start, num_pages, FOLL_WRITE,
> + shm->pages);
> + } else {
> + const struct kvec kiov = {
> + .iov_base = (void *)start,
> + .iov_len = PAGE_SIZE
> + };
> +
> + rc = get_kernel_pages(&kiov, num_pages, 0, shm->pages);
Passing a single kvec struct is temporary I assume? Because as currently
written this will only work with num_pages==1.
Stuart
^ permalink raw reply
* Re: PCI: Correct the resource_alignment parameter example
From: Bjorn Helgaas @ 2019-08-08 20:15 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: linux-kernel, linux-doc, linux-pci
In-Reply-To: <20190606032557.107542-1-aik@ozlabs.ru>
On Thu, Jun 06, 2019 at 01:25:57PM +1000, Alexey Kardashevskiy wrote:
> The option description requires an order and so does the option
> parsing code, however the example uses a size, fix this.
>
> Fixes: 8b078c603249 ("PCI: Update "pci=resource_alignment" documentation")
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Applied to pci/resource for v5.4, thanks!
> ---
> Documentation/admin-guide/kernel-parameters.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 2b8ee90bb644..dcb53d64ad74 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -3340,27 +3340,28 @@
> resource_alignment=
> Format:
> [<order of align>@]<pci_dev>[; ...]
> Specifies alignment and device to reassign
> aligned memory resources. How to
> specify the device is described above.
> If <order of align> is not specified,
> PAGE_SIZE is used as alignment.
> PCI-PCI bridge can be specified, if resource
> windows need to be expanded.
> To specify the alignment for several
> instances of a device, the PCI vendor,
> device, subvendor, and subdevice may be
> - specified, e.g., 4096@pci:8086:9c22:103c:198f
> + specified, e.g., 12@pci:8086:9c22:103c:198f
> + for the 4096 alignment.
> ecrc= Enable/disable PCIe ECRC (transaction layer
> end-to-end CRC checking).
> bios: Use BIOS/firmware settings. This is the
> the default.
> off: Turn ECRC off
> on: Turn ECRC on.
> hpiosize=nn[KMG] The fixed amount of bus space which is
> reserved for hotplug bridge's IO window.
> Default size is 256 bytes.
> hpmemsize=nn[KMG] The fixed amount of bus space which is
> reserved for hotplug bridge's memory window.
> Default size is 2 megabytes.
> hpbussize=nn The minimum amount of additional bus numbers
> --
> 2.17.1
>
^ permalink raw reply
* Re: [Linux-decnet-user] [PATCH] Documentation: decnet: remove reference to CONFIG_DECNET_ROUTE_FWMARK
From: David Miller @ 2019-08-08 18:21 UTC (permalink / raw)
To: emserrat
Cc: clabbe, corbet, linux-doc, netdev, linux-decnet-user,
linux-kernel, tgraf
In-Reply-To: <DM5PR22MB03797234267E8B37EA3080BBC4D70@DM5PR22MB0379.namprd22.prod.outlook.com>
From: Eduardo Marcelo Serrat <emserrat@hotmail.com>
Date: Thu, 8 Aug 2019 11:44:14 +0000
> Sorry for using the list for this purpose but we are looking for
> senior engineers with knowledge in OpenVMS/ Tru64 Unix, Solaris,
> HP-UX and of course Linux and familiar with virtualization
> technologies, specially cross platform emulators. We need to fill
> support engineer roles. If anybody interested for positions in the
> US / Europe please send me an email.
Please do not ever use the vger.kernel.org mailing lists for this kind
of solicitation.
It is completely inappropriate.
^ permalink raw reply
* Re: [PATCH v7 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst
From: Catalin Marinas @ 2019-08-08 17:27 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-arm-kernel, Vincenzo Frascino, Will Deacon,
Andrey Konovalov, Szabolcs Nagy, Kevin Brodsky, linux-doc,
linux-arch
In-Reply-To: <826a9ace-feac-c019-843e-07e23c9fd46c@intel.com>
On Wed, Aug 07, 2019 at 01:38:16PM -0700, Dave Hansen wrote:
> On 8/7/19 8:53 AM, Catalin Marinas wrote:
> > +- mmap() done by the process itself (or its parent), where either:
> > +
> > + - flags have the **MAP_ANONYMOUS** bit set
> > + - the file descriptor refers to a regular file (including those returned
> > + by memfd_create()) or **/dev/zero**
>
> What's a "regular file"? ;)
We could make it more explicit like '(stat.st_mode & S_IFMT) == S_IFREG'
but it gets too verbose ;).
> > +- brk() system call done by the process itself (i.e. the heap area between
> > + the initial location of the program break at process creation and its
> > + current location).
> > +
> > +- any memory mapped by the kernel in the address space of the process
> > + during creation and with the same restrictions as for mmap() above (e.g.
> > + data, bss, stack).
> > +
> > +The AArch64 Tagged Address ABI is an opt-in feature and an application can
> > +control it via **prctl()** as follows:
> > +
> > +- **PR_SET_TAGGED_ADDR_CTRL**: enable or disable the AArch64 Tagged Address
> > + ABI for the calling process.
> > +
> > + The (unsigned int) arg2 argument is a bit mask describing the control mode
> > + used:
> > +
> > + - **PR_TAGGED_ADDR_ENABLE**: enable AArch64 Tagged Address ABI. Default
> > + status is disabled.
> > +
> > + The arguments arg3, arg4, and arg5 are ignored.
>
> For previous prctl()'s, we've found that it's best to require that the
> unused arguments be 0. Without that, apps are free to put garbage
> there, which makes extending the prctl to use other arguments impossible
> in the future.
We've had a bit of bikeshedding already:
http://lkml.kernel.org/r/20190613110235.GW28398@e103592.cambridge.arm.com
Extending the interface is still possible even with the current
proposal, by changing arg2 etc. We also don't seem to be consistent in
sys_prctl().
> Also, shouldn't this be converted over to an arch_prctl()?
What do you mean by arch_prctl()? We don't have such thing, apart from
maybe arch_prctl_spec_ctrl_*(). We achieve the same thing with the
{SET,GET}_TAGGED_ADDR_CTRL macros. They could be renamed to
arch_prctl_tagged_addr_{set,get} or something but I don't see much
point.
What would be better (for a separate patch series) is to clean up
sys_prctl() and move the arch-specific options into separate
arch_prctl() under arch/*/kernel/. But it's not really for this series.
> > +The prctl(PR_SET_TAGGED_ADDR_CTRL, ...) will return -EINVAL if the
> > +AArch64 Tagged Address ABI is not available
> > +(CONFIG_ARM64_TAGGED_ADDR_ABI disabled or sysctl abi.tagged_addr=0).
> > +
> > +The ABI properties set by the mechanism described above are inherited by
> > +threads of the same application and fork()'ed children but cleared by
> > +execve().
>
> What is the scope of these prctl()'s? Are they thread-scoped or
> process-scoped? Can two threads in the same process run with different
> tagging ABI modes?
Good point. They are thread-scoped and this should be made clear in the
doc. Two threads can have different modes.
The expectation is that this is invoked early during process start (by
the dynamic loader or libc init) while in single-thread mode and
subsequent threads will inherit the same mode. However, other uses are
possible.
> > +Opting in (the prctl() option described above only) to or out of the
> > +AArch64 Tagged Address ABI can be disabled globally at runtime using the
> > +sysctl interface:
> > +
> > +- **abi.tagged_addr**: a new sysctl interface that can be used to prevent
> > + applications from enabling or disabling the relaxed ABI. The sysctl
> > + supports the following configuration options:
> > +
> > + - **0**: disable the prctl(PR_SET_TAGGED_ADDR_CTRL) option to
> > + enable/disable the AArch64 Tagged Address ABI globally
> > +
> > + - **1** (Default): enable the prctl(PR_SET_TAGGED_ADDR_CTRL) option to
> > + enable/disable the AArch64 Tagged Address ABI globally
> > +
> > + Note that this sysctl does not affect the status of the AArch64 Tagged
> > + Address ABI of the running processes.
>
> Shouldn't the name be "abi.tagged_addr_control" or something? It
> actually has *zero* direct effect on tagged addresses in the ABI.
Yeah, we could add a _ctrl suffix. I usually lack inspiration when
naming things.
> What's the reason for allowing it to be toggled at runtime like this?
> Wouldn't it make more sense to just have it be a boot option so you
> *know* what the state of individual processes is?
This was initially suggested by Vincenzo but I wasn't keen on having a
kernel command line option that affects the user ABI. Since then we went
through several incarnations and ended up with a default off for the
relaxed ABI with an opt-in prctl(). The reason behind default off is
that I'm not 100% confident the kernel won't break the relaxed ABI in
the future and I wouldn't want applications that don't use
top-byte-ignore (or tagged addresses) to inadvertently start using it.
The additional sysctl is to allow system administrators to block the
opt-in altogether. It also comes in handy for testing userspace
behaviour without rebooting.
That said, do we have a precedent for changing user ABI from the kernel
cmd line? 'noexec32', 'vsyscall' I think come close. With the prctl()
for opt-in, controlling this from the cmd line is not too bad (though my
preference is still for the sysctl).
> > +When a process has successfully enabled the new ABI by invoking
> > +prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE), the following
> > +behaviours are guaranteed:
> > +
> > +- Every currently available syscall, except the cases mentioned in section
> > + 3, can accept any valid tagged pointer. The same rule is applicable to
> > + any syscall introduced in the future.
> > +
> > +- The syscall behaviour is undefined for non valid tagged pointers.
>
> Do you really mean "undefined"? I mean, a bad pointer is a bad pointer.
> Why should it matter if it's a tagged bad pointer or an untagged bad
> pointer?
Szabolcs already replied here. We may have tagged pointers that can be
dereferenced just fine but being passed to the kernel may not be well
defined (e.g. some driver doing a find_vma() that fails unless it
explicitly untags the address). It's as undefined as the current
behaviour (without these patches) guarantees.
> ...
> > +A definition of the meaning of tagged pointers on AArch64 can be found in:
> > +Documentation/arm64/tagged-pointers.txt.
> > +
> > +3. AArch64 Tagged Address ABI Exceptions
> > +-----------------------------------------
> > +
> > +The behaviour described in section 2, with particular reference to the
> > +acceptance by the syscalls of any valid tagged pointer, is not applicable
> > +to the following cases:
>
> This is saying things in a pretty roundabout manner. Can't it just say:
> "The following cases do not accept tagged pointers:"
I agree.
> > +- mmap() addr parameter.
> > +
> > +- mremap() new_address parameter.
>
> Is munmap() missing? Or was there a reason for leaving it out?
Szabolcs replied already here.
For a bit of history, I initially didn't want any of the address space
handling functions to accept tagged pointers but it got harder to
specify what this means that can be safely applied to future syscall
extensions. We then changed the approach to allow it everywhere with
some exclusions like mmap/mremap.
> > +- prctl(PR_SET_MM, ``*``, ...) other than arg2 PR_SET_MM_MAP and
> > + PR_SET_MM_MAP_SIZE.
> > +
> > +- prctl(PR_SET_MM, PR_SET_MM_MAP{,_SIZE}, ...) struct prctl_mm_map fields.
> > +
> > +Any attempt to use non-zero tagged pointers will lead to undefined
> > +behaviour.
>
> I wonder if you want to generalize this a bit. I think you're saying
> that parts of the ABI that modify the *layout* of the address space
> never accept tagged pointers.
I guess our difficulty in specifying this may have been caused by
over-generalising. For example, madvise/mprotect came under the same
category but there is a use-case for malloc'ed pointers (and tagged) to
the kernel (e.g. MADV_DONTNEED). If we can restrict the meaning to
address space *layout* manipulation, we'd have mmap/mremap/munmap,
brk/sbrk, prctl(PR_SET_MM). Did I miss anything?. Other related syscalls
like mprotect/madvise preserve the layout while only changing permissions,
backing store, so the would be allowed to accept tags.
Open to feedback from others, especially libc/userspace folk. Ideally,
what I'd like is that when a new syscall is added (or extension to an
existing syscall), it should be fairly obvious to the user whether it
can take a tagged address or not (or maybe that's just not possible).
> > +4. Example of correct usage
> > +---------------------------
> > +.. code-block:: c
> > +
> > + void main(void)
> > + {
> > + static int tbi_enabled = 0;
> > + unsigned long tag = 0;
> > +
> > + char *ptr = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE,
> > + MAP_ANONYMOUS, -1, 0);
> > +
> > + if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE,
> > + 0, 0, 0) == 0)
> > + tbi_enabled = 1;
> > +
> > + if (ptr == (void *)-1) /* MAP_FAILED */
> > + return -1;
> > +
> > + if (tbi_enabled)
> > + tag = rand() & 0xff;
> > +
> > + ptr = (char *)((unsigned long)ptr | (tag << TAG_SHIFT));
> > +
> > + *ptr = 'a';
> > +
> > + ...
> > + }
>
> It looks like the TAG_SHIFT and tag size are pretty baked into the
> aarch64 architecture. But, are you confident that no future
> implementations will want different positions or sizes? (obviously
> controlled by other TCR_EL1 bits)
For the top-byte-ignore (TBI), that's been baked in the architecture
since ARMv8.0 and we'll have to keep the backwards compatible mode. As
the name implies, it's the top byte of the address and that's what the
document above refers to.
With MTE, I can't exclude other configurations in the future but I'd
expect the kernel to present the option as a new HWCAP and the user to
explicitly opt in via a new prctl() flag. I seriously doubt we'd break
existing binaries. So, yes TAG_SHIFT may be different but so would the
prctl() above.
Thanks.
--
Catalin
^ permalink raw reply
* Re: [PATCH 5/6] tty: serial: Add linflexuart driver for S32V234
From: Will Deacon @ 2019-08-08 17:17 UTC (permalink / raw)
To: Stefan-gabriel Mirea
Cc: corbet@lwn.net, robh+dt@kernel.org, mark.rutland@arm.com,
gregkh@linuxfoundation.org, catalin.marinas@arm.com,
shawnguo@kernel.org, Leo Li, jslaby@suse.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-serial@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Cosmin Stefan Stoica,
Larisa Ileana Grigore
In-Reply-To: <VI1PR0402MB28635661A4A294EC6F01095EDFD70@VI1PR0402MB2863.eurprd04.prod.outlook.com>
Hi,
On Thu, Aug 08, 2019 at 12:47:00PM +0000, Stefan-gabriel Mirea wrote:
> On 8/8/2019 11:08 AM, Will Deacon wrote:
> > On Fri, Aug 02, 2019 at 07:47:23PM +0000, Stefan-gabriel Mirea wrote:
> >> + linflex,<addr>
> >> + Use early console provided by Freescale LinFlex UART
> >> + serial driver for NXP S32V234 SoCs. A valid base
> >> + address must be provided, and the serial port must
> >> + already be setup and configured.
> >
> > Why isn't earlycon= sufficient for this?
>
> "earlycon=" is not actually supported. I will fix this in the next
> version by adding a /chosen/stdout-path to the dts. The compatible
> string provided to OF_EARLYCON_DECLARE will also be changed from
> "fsl,s32v234-linflexuart" to "fsl,s32-linflexuart" to match the one in
> the device tree nodes. I missed this after importing a rename from our
> codebase.
>
> Should I remove this addition from kernel-parameters.txt after that?
Yes, if you can use earlycon instead, then you can drop your custom option
entirely and therefore there's no need to document it either.
Will
^ permalink raw reply
* Re: [PATCH v7 2/2] arm64: Relax Documentation/arm64/tagged-pointers.rst
From: Will Deacon @ 2019-08-08 17:06 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-arm-kernel, linux-arch, linux-doc, Szabolcs Nagy,
Andrey Konovalov, Kevin Brodsky, Will Deacon, Dave Hansen,
Vincenzo Frascino
In-Reply-To: <20190807155321.9648-3-catalin.marinas@arm.com>
On Wed, Aug 07, 2019 at 04:53:21PM +0100, Catalin Marinas wrote:
> From: Vincenzo Frascino <vincenzo.frascino@arm.com>
>
> On arm64 the TCR_EL1.TBI0 bit has been always enabled hence
> the userspace (EL0) is allowed to set a non-zero value in the
> top byte but the resulting pointers are not allowed at the
> user-kernel syscall ABI boundary.
>
> With the relaxed ABI proposed in this set, it is now possible to pass
> tagged pointers to the syscalls, when these pointers are in memory
> ranges obtained by an anonymous (MAP_ANONYMOUS) mmap().
>
> Relax the requirements described in tagged-pointers.rst to be compliant
> with the behaviours guaranteed by the ARM64 Tagged Address ABI.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Andrey Konovalov <andreyknvl@google.com>
> Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>
> Cc: Kevin Brodsky <kevin.brodsky@arm.com>
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
> [catalin.marinas@arm.com: minor tweaks]
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> Documentation/arm64/tagged-pointers.rst | 23 ++++++++++++++++-------
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/arm64/tagged-pointers.rst b/Documentation/arm64/tagged-pointers.rst
> index 2acdec3ebbeb..82a3eff71a70 100644
> --- a/Documentation/arm64/tagged-pointers.rst
> +++ b/Documentation/arm64/tagged-pointers.rst
> @@ -20,7 +20,8 @@ Passing tagged addresses to the kernel
> --------------------------------------
>
> All interpretation of userspace memory addresses by the kernel assumes
> -an address tag of 0x00.
> +an address tag of 0x00, unless the application enables the AArch64
> +Tagged Address ABI explicitly.
I think we should have the link to Documentation/arm64/tagged-address-abi.rst
here so people see it when it's first referenced.
> +The AArch64 Tagged Address ABI description and the guarantees it
> +provides can be found in: Documentation/arm64/tagged-address-abi.rst.
Then this sentence can be dropped.
Will
^ permalink raw reply
* Re: [PATCH v7 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst
From: Will Deacon @ 2019-08-08 17:04 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-arm-kernel, linux-arch, linux-doc, Szabolcs Nagy,
Andrey Konovalov, Kevin Brodsky, Will Deacon, Dave Hansen,
Vincenzo Frascino
In-Reply-To: <20190807155321.9648-2-catalin.marinas@arm.com>
On Wed, Aug 07, 2019 at 04:53:20PM +0100, Catalin Marinas wrote:
> From: Vincenzo Frascino <vincenzo.frascino@arm.com>
>
> On arm64 the TCR_EL1.TBI0 bit has been always enabled hence
> the userspace (EL0) is allowed to set a non-zero value in the
> top byte but the resulting pointers are not allowed at the
> user-kernel syscall ABI boundary.
>
> With the relaxed ABI proposed through this document, it is now possible
> to pass tagged pointers to the syscalls, when these pointers are in
> memory ranges obtained by an anonymous (MAP_ANONYMOUS) mmap().
>
> This change in the ABI requires a mechanism to requires the userspace
> to opt-in to such an option.
>
> Specify and document the way in which sysctl and prctl() can be used
> in combination to allow the userspace to opt-in this feature.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Andrey Konovalov <andreyknvl@google.com>
> Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>
> Cc: Kevin Brodsky <kevin.brodsky@arm.com>
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
> [catalin.marinas@arm.com: some rewording, dropped MAP_PRIVATE]
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> Documentation/arm64/tagged-address-abi.rst | 151 +++++++++++++++++++++
> 1 file changed, 151 insertions(+)
> create mode 100644 Documentation/arm64/tagged-address-abi.rst
>
> diff --git a/Documentation/arm64/tagged-address-abi.rst b/Documentation/arm64/tagged-address-abi.rst
> new file mode 100644
> index 000000000000..f91a5d2ac865
> --- /dev/null
> +++ b/Documentation/arm64/tagged-address-abi.rst
> @@ -0,0 +1,151 @@
> +==========================
> +AArch64 TAGGED ADDRESS ABI
> +==========================
> +
> +Author: Vincenzo Frascino <vincenzo.frascino@arm.com>
> +
> +Date: 25 July 2019
> +
> +This document describes the usage and semantics of the Tagged Address
> +ABI on AArch64 Linux.
> +
> +1. Introduction
> +---------------
> +
> +On AArch64 the TCR_EL1.TBI0 bit has always been enabled, allowing userspace
> +(EL0) to perform memory accesses through 64-bit pointers with a non-zero
> +top byte. Such tagged pointers, however, were not allowed at the
> +user-kernel syscall ABI boundary.
I think we should drop the temporal language, so:
"has always been enabled" => "is set by the kernel"
"were not allowed" => "are not allowed by default"
> +
> +This document describes the relaxation of the syscall ABI that allows
> +userspace to pass certain tagged pointers to kernel syscalls, as described
> +in section 2.
> +
> +2. AArch64 Tagged Address ABI
> +-----------------------------
> +
> +From the kernel syscall interface perspective and for the purposes of this
> +document, a "valid tagged pointer" is a pointer with a potentially non-zero
> +top-byte that references an address in the user process address space
> +obtained in one of the following ways:
> +
> +- mmap() done by the process itself (or its parent), where either:
> +
> + - flags have the **MAP_ANONYMOUS** bit set
> + - the file descriptor refers to a regular file (including those returned
> + by memfd_create()) or **/dev/zero**
> +
> +- brk() system call done by the process itself (i.e. the heap area between
> + the initial location of the program break at process creation and its
> + current location).
> +
> +- any memory mapped by the kernel in the address space of the process
> + during creation and with the same restrictions as for mmap() above (e.g.
> + data, bss, stack).
> +
> +The AArch64 Tagged Address ABI is an opt-in feature and an application can
> +control it via **prctl()** as follows:
> +
> +- **PR_SET_TAGGED_ADDR_CTRL**: enable or disable the AArch64 Tagged Address
> + ABI for the calling process.
> +
> + The (unsigned int) arg2 argument is a bit mask describing the control mode
> + used:
> +
> + - **PR_TAGGED_ADDR_ENABLE**: enable AArch64 Tagged Address ABI. Default
> + status is disabled.
> +
> + The arguments arg3, arg4, and arg5 are ignored.
> +
> +- **PR_GET_TAGGED_ADDR_CTRL**: get the status of the AArch64 Tagged Address
> + ABI for the calling process.
> +
> + The arguments arg2, arg3, arg4, and arg5 are ignored.
I agree with Dave (H) that we should require these to be zero. We may be
able to use arg2 to namespace things for PR_SET_TAGGED_ADDR_CTRL, but for
PR_GET_TAGGED_ADDR_CTRL we'd have to add a new prctl if we wanted to extend
it otherwise.
> +The prctl(PR_SET_TAGGED_ADDR_CTRL, ...) will return -EINVAL if the
*The* prctl? Maybe "Calling prctl(..." is better?
> +AArch64 Tagged Address ABI is not available
> +(CONFIG_ARM64_TAGGED_ADDR_ABI disabled or sysctl abi.tagged_addr=0).
drop the brackets and say "because CONFIG_... is disabled or ..".
> +
> +The ABI properties set by the mechanism described above are inherited by
> +threads of the same application and fork()'ed children but cleared by
> +execve().
Maybe just exec() here, since there are other flavours we shouldn't need to
enumerate.
> +Opting in (the prctl() option described above only) to or out of the
> +AArch64 Tagged Address ABI can be disabled globally at runtime using the
> +sysctl interface:
This sentence reads really badly thanks to the random bracketed part.
> +
> +- **abi.tagged_addr**: a new sysctl interface that can be used to prevent
> + applications from enabling or disabling the relaxed ABI. The sysctl
> + supports the following configuration options:
> +
> + - **0**: disable the prctl(PR_SET_TAGGED_ADDR_CTRL) option to
> + enable/disable the AArch64 Tagged Address ABI globally
This is clunky because it sounds like we're enabling the ABI for everybody,
where in actual fact we're enabling the controls for the ABI instead. It
also applies equally to PR_GET_TAGGED_ADDR_CTRL (but see below). Given that
we've already defined the prctl() above, I think we can just say:
**0**: AArch64 Tagged Address ABI prctl() calls will return -EINVAL
**1**: AArch64 Tagged Address ABI prctl() calls will behave as documented above.
> + - **1** (Default): enable the prctl(PR_SET_TAGGED_ADDR_CTRL) option to
> + enable/disable the AArch64 Tagged Address ABI globally
> +
> + Note that this sysctl does not affect the status of the AArch64 Tagged
> + Address ABI of the running processes.
Hmm, but it does mean that you can no longer ask if a previously running
process is using tags. Is that intentional?
> +When a process has successfully enabled the new ABI by invoking
> +prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE), the following
> +behaviours are guaranteed:
nit: this also applies to processes that have inherited the new ABI
bevaiour via fork() and haven't invoked the prctl() themselves.
> +- Every currently available syscall, except the cases mentioned in section
"currently available" is meaningless and should be removed
> + 3, can accept any valid tagged pointer. The same rule is applicable to
> + any syscall introduced in the future.
Delete this last sentence.
> +- The syscall behaviour is undefined for non valid tagged pointers.
non valid => invalid
although this needs to be better defined, I think.
> +
> +- Every valid tagged pointer is expected to work as an untagged one.
What does that mean? Expected by who? What does "work" mean?
> +A definition of the meaning of tagged pointers on AArch64 can be found in:
> +Documentation/arm64/tagged-pointers.txt.
.txt => .rst
> +
> +3. AArch64 Tagged Address ABI Exceptions
> +-----------------------------------------
> +
> +The behaviour described in section 2, with particular reference to the
> +acceptance by the syscalls of any valid tagged pointer, is not applicable
> +to the following cases:
Jeez louise...
How about: "The following system call parameters must be untagged, regardless
of the ABI relaxation:"
> +
> +- mmap() addr parameter.
> +
> +- mremap() new_address parameter.
> +
> +- prctl(PR_SET_MM, ``*``, ...) other than arg2 PR_SET_MM_MAP and
> + PR_SET_MM_MAP_SIZE.
> +
> +- prctl(PR_SET_MM, PR_SET_MM_MAP{,_SIZE}, ...) struct prctl_mm_map fields.
How did you generate this list and who will keep it up to date? How do you
know you haven't missed anything?
> +Any attempt to use non-zero tagged pointers will lead to undefined
> +behaviour.
In the tagged pointer document we're slightly more specific and say that
using non-zero address tags "may result in an error code being returned, a
(fatal) signal being rasied, or other modes of failure". Maybe reuse that?
> +4. Example of correct usage
> +---------------------------
> +.. code-block:: c
> +
> + void main(void)
> + {
> + static int tbi_enabled = 0;
> + unsigned long tag = 0;
> +
Some comments won't go amiss here.
> + char *ptr = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE,
> + MAP_ANONYMOUS, -1, 0);
> +
> + if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE,
> + 0, 0, 0) == 0)
> + tbi_enabled = 1;
> +
> + if (ptr == (void *)-1) /* MAP_FAILED */
> + return -1;
> +
> + if (tbi_enabled)
> + tag = rand() & 0xff;
> +
> + ptr = (char *)((unsigned long)ptr | (tag << TAG_SHIFT));
> +
> + *ptr = 'a';
> +
> + ...
> + }
Hmm, doesn't this snippet work today? You're not actually passing the
tagged pointer back to the kernel...
Will
^ permalink raw reply
* [PATCH 2/2] Documentation/arm/sa1100/assabet: Fix 'make assabet_defconfig' command
From: Jonathan Neuschäfer @ 2019-08-08 16:58 UTC (permalink / raw)
To: linux-doc
Cc: linux-arm-kernel, Jonathan Neuschäfer, Jonathan Corbet,
Mauro Carvalho Chehab, linux-kernel
In-Reply-To: <20190808165929.16946-1-j.neuschaefer@gmx.net>
"make assabet_config" doesn't work.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
Documentation/arm/sa1100/assabet.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/arm/sa1100/assabet.rst b/Documentation/arm/sa1100/assabet.rst
index 3e704831c311..a761e128fb08 100644
--- a/Documentation/arm/sa1100/assabet.rst
+++ b/Documentation/arm/sa1100/assabet.rst
@@ -14,7 +14,7 @@ Building the kernel
To build the kernel with current defaults::
- make assabet_config
+ make assabet_defconfig
make oldconfig
make zImage
--
2.20.1
^ permalink raw reply related
* [PATCH 1/2] Documentation/arm/sa1100: Remove some obsolete documentation
From: Jonathan Neuschäfer @ 2019-08-08 16:58 UTC (permalink / raw)
To: linux-doc
Cc: linux-arm-kernel, Jonathan Neuschäfer, Jonathan Corbet,
Mauro Carvalho Chehab, linux-kernel
The support for the following boards, among others, was removed in 2004
with commit "[ARM] Remove broken SA1100 machine support.":
- ADS Bitsy
- Brutus
- Freebird
- ADS GraphicsClient Plus
- ADS GraphicsMaster
- Höft & Wessel Webpanel
- Compaq Itsy
- nanoEngine
- Pangolin
- PLEB
- Yopy
Tifon support has been removed in 2.4.3.3.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
Documentation/arm/sa1100/adsbitsy.rst | 51 ----------
Documentation/arm/sa1100/brutus.rst | 69 -------------
Documentation/arm/sa1100/freebird.rst | 25 -----
Documentation/arm/sa1100/graphicsclient.rst | 102 --------------------
Documentation/arm/sa1100/graphicsmaster.rst | 60 ------------
Documentation/arm/sa1100/huw_webpanel.rst | 21 ----
Documentation/arm/sa1100/index.rst | 12 ---
Documentation/arm/sa1100/itsy.rst | 47 ---------
Documentation/arm/sa1100/nanoengine.rst | 11 ---
Documentation/arm/sa1100/pangolin.rst | 29 ------
Documentation/arm/sa1100/pleb.rst | 13 ---
Documentation/arm/sa1100/tifon.rst | 7 --
Documentation/arm/sa1100/yopy.rst | 5 -
13 files changed, 452 deletions(-)
delete mode 100644 Documentation/arm/sa1100/adsbitsy.rst
delete mode 100644 Documentation/arm/sa1100/brutus.rst
delete mode 100644 Documentation/arm/sa1100/freebird.rst
delete mode 100644 Documentation/arm/sa1100/graphicsclient.rst
delete mode 100644 Documentation/arm/sa1100/graphicsmaster.rst
delete mode 100644 Documentation/arm/sa1100/huw_webpanel.rst
delete mode 100644 Documentation/arm/sa1100/itsy.rst
delete mode 100644 Documentation/arm/sa1100/nanoengine.rst
delete mode 100644 Documentation/arm/sa1100/pangolin.rst
delete mode 100644 Documentation/arm/sa1100/pleb.rst
delete mode 100644 Documentation/arm/sa1100/tifon.rst
delete mode 100644 Documentation/arm/sa1100/yopy.rst
diff --git a/Documentation/arm/sa1100/adsbitsy.rst b/Documentation/arm/sa1100/adsbitsy.rst
deleted file mode 100644
index c179cb26b682..000000000000
--- a/Documentation/arm/sa1100/adsbitsy.rst
+++ /dev/null
@@ -1,51 +0,0 @@
-===============================
-ADS Bitsy Single Board Computer
-===============================
-
-(It is different from Bitsy(iPAQ) of Compaq)
-
-For more details, contact Applied Data Systems or see
-http://www.applieddata.net/products.html
-
-The Linux support for this product has been provided by
-Woojung Huh <whuh@applieddata.net>
-
-Use 'make adsbitsy_config' before any 'make config'.
-This will set up defaults for ADS Bitsy support.
-
-The kernel zImage is linked to be loaded and executed at 0xc0400000.
-
-Linux can be used with the ADS BootLoader that ships with the
-newer rev boards. See their documentation on how to load Linux.
-
-Supported peripherals
-=====================
-
-- SA1100 LCD frame buffer (8/16bpp...sort of)
-- SA1111 USB Master
-- SA1100 serial port
-- pcmcia, compact flash
-- touchscreen(ucb1200)
-- console on LCD screen
-- serial ports (ttyS[0-2])
- - ttyS0 is default for serial console
-
-To do
-=====
-
-- everything else! :-)
-
-Notes
-=====
-
-- The flash on board is divided into 3 partitions.
- You should be careful to use flash on board.
- Its partition is different from GraphicsClient Plus and GraphicsMaster
-
-- 16bpp mode requires a different cable than what ships with the board.
- Contact ADS or look through the manual to wire your own. Currently,
- if you compile with 16bit mode support and switch into a lower bpp
- mode, the timing is off so the image is corrupted. This will be
- fixed soon.
-
-Any contribution can be sent to nico@fluxnic.net and will be greatly welcome!
diff --git a/Documentation/arm/sa1100/brutus.rst b/Documentation/arm/sa1100/brutus.rst
deleted file mode 100644
index e1a23bee6d44..000000000000
--- a/Documentation/arm/sa1100/brutus.rst
+++ /dev/null
@@ -1,69 +0,0 @@
-======
-Brutus
-======
-
-Brutus is an evaluation platform for the SA1100 manufactured by Intel.
-For more details, see:
-
-http://developer.intel.com
-
-To compile for Brutus, you must issue the following commands::
-
- make brutus_config
- make config
- [accept all the defaults]
- make zImage
-
-The resulting kernel will end up in linux/arch/arm/boot/zImage. This file
-must be loaded at 0xc0008000 in Brutus's memory and execution started at
-0xc0008000 as well with the value of registers r0 = 0 and r1 = 16 upon
-entry.
-
-But prior to execute the kernel, a ramdisk image must also be loaded in
-memory. Use memory address 0xd8000000 for this. Note that the file
-containing the (compressed) ramdisk image must not exceed 4 MB.
-
-Typically, you'll need angelboot to load the kernel.
-The following angelboot.opt file should be used::
-
- base 0xc0008000
- entry 0xc0008000
- r0 0x00000000
- r1 0x00000010
- device /dev/ttyS0
- options "9600 8N1"
- baud 115200
- otherfile ramdisk_img.gz
- otherbase 0xd8000000
-
-Then load the kernel and ramdisk with::
-
- angelboot -f angelboot.opt zImage
-
-The first Brutus serial port (assumed to be linked to /dev/ttyS0 on your
-host PC) is used by angel to load the kernel and ramdisk image. The serial
-console is provided through the second Brutus serial port. To access it,
-you may use minicom configured with /dev/ttyS1, 9600 baud, 8N1, no flow
-control.
-
-Currently supported
-===================
-
- - RS232 serial ports
- - audio output
- - LCD screen
- - keyboard
-
-The actual Brutus support may not be complete without extra patches.
-If such patches exist, they should be found from
-ftp.netwinder.org/users/n/nico.
-
-A full PCMCIA support is still missing, although it's possible to hack
-some drivers in order to drive already inserted cards at boot time with
-little modifications.
-
-Any contribution is welcome.
-
-Please send patches to nico@fluxnic.net
-
-Have Fun !
diff --git a/Documentation/arm/sa1100/freebird.rst b/Documentation/arm/sa1100/freebird.rst
deleted file mode 100644
index 81043d0c6d64..000000000000
--- a/Documentation/arm/sa1100/freebird.rst
+++ /dev/null
@@ -1,25 +0,0 @@
-========
-Freebird
-========
-
-Freebird-1.1 is produced by Legend(C), Inc.
-`http://web.archive.org/web/*/http://www.legend.com.cn`
-and software/linux maintained by Coventive(C), Inc.
-(http://www.coventive.com)
-
-Based on the Nicolas's strongarm kernel tree.
-
-Maintainer:
-
-Chester Kuo
- - <chester@coventive.com>
- - <chester@linux.org.tw>
-
-Author:
-
-- Tim wu <timwu@coventive.com>
-- CIH <cih@coventive.com>
-- Eric Peng <ericpeng@coventive.com>
-- Jeff Lee <jeff_lee@coventive.com>
-- Allen Cheng
-- Tony Liu <tonyliu@coventive.com>
diff --git a/Documentation/arm/sa1100/graphicsclient.rst b/Documentation/arm/sa1100/graphicsclient.rst
deleted file mode 100644
index a73d61c3ce91..000000000000
--- a/Documentation/arm/sa1100/graphicsclient.rst
+++ /dev/null
@@ -1,102 +0,0 @@
-=============================================
-ADS GraphicsClient Plus Single Board Computer
-=============================================
-
-For more details, contact Applied Data Systems or see
-http://www.applieddata.net/products.html
-
-The original Linux support for this product has been provided by
-Nicolas Pitre <nico@fluxnic.net>. Continued development work by
-Woojung Huh <whuh@applieddata.net>
-
-It's currently possible to mount a root filesystem via NFS providing a
-complete Linux environment. Otherwise a ramdisk image may be used. The
-board supports MTD/JFFS, so you could also mount something on there.
-
-Use 'make graphicsclient_config' before any 'make config'. This will set up
-defaults for GraphicsClient Plus support.
-
-The kernel zImage is linked to be loaded and executed at 0xc0200000.
-Also the following registers should have the specified values upon entry::
-
- r0 = 0
- r1 = 29 (this is the GraphicsClient architecture number)
-
-Linux can be used with the ADS BootLoader that ships with the
-newer rev boards. See their documentation on how to load Linux.
-Angel is not available for the GraphicsClient Plus AFAIK.
-
-There is a board known as just the GraphicsClient that ADS used to
-produce but has end of lifed. This code will not work on the older
-board with the ADS bootloader, but should still work with Angel,
-as outlined below. In any case, if you're planning on deploying
-something en masse, you should probably get the newer board.
-
-If using Angel on the older boards, here is a typical angel.opt option file
-if the kernel is loaded through the Angel Debug Monitor::
-
- base 0xc0200000
- entry 0xc0200000
- r0 0x00000000
- r1 0x0000001d
- device /dev/ttyS1
- options "38400 8N1"
- baud 115200
- #otherfile ramdisk.gz
- #otherbase 0xc0800000
- exec minicom
-
-Then the kernel (and ramdisk if otherfile/otherbase lines above are
-uncommented) would be loaded with::
-
- angelboot -f angelboot.opt zImage
-
-Here it is assumed that the board is connected to ttyS1 on your PC
-and that minicom is preconfigured with /dev/ttyS1, 38400 baud, 8N1, no flow
-control by default.
-
-If any other bootloader is used, ensure it accomplish the same, especially
-for r0/r1 register values before jumping into the kernel.
-
-
-Supported peripherals
-=====================
-
-- SA1100 LCD frame buffer (8/16bpp...sort of)
-- on-board SMC 92C96 ethernet NIC
-- SA1100 serial port
-- flash memory access (MTD/JFFS)
-- pcmcia
-- touchscreen(ucb1200)
-- ps/2 keyboard
-- console on LCD screen
-- serial ports (ttyS[0-2])
- - ttyS0 is default for serial console
-- Smart I/O (ADC, keypad, digital inputs, etc)
- See http://www.eurotech-inc.com/linux-sbc.asp for IOCTL documentation
- and example user space code. ps/2 keybd is multiplexed through this driver
-
-To do
-=====
-
-- UCB1200 audio with new ucb_generic layer
-- everything else! :-)
-
-Notes
-=====
-
-- The flash on board is divided into 3 partitions. mtd0 is where
- the ADS boot ROM and zImage is stored. It's been marked as
- read-only to keep you from blasting over the bootloader. :) mtd1 is
- for the ramdisk.gz image. mtd2 is user flash space and can be
- utilized for either JFFS or if you're feeling crazy, running ext2
- on top of it. If you're not using the ADS bootloader, you're
- welcome to blast over the mtd1 partition also.
-
-- 16bpp mode requires a different cable than what ships with the board.
- Contact ADS or look through the manual to wire your own. Currently,
- if you compile with 16bit mode support and switch into a lower bpp
- mode, the timing is off so the image is corrupted. This will be
- fixed soon.
-
-Any contribution can be sent to nico@fluxnic.net and will be greatly welcome!
diff --git a/Documentation/arm/sa1100/graphicsmaster.rst b/Documentation/arm/sa1100/graphicsmaster.rst
deleted file mode 100644
index e39892514f0c..000000000000
--- a/Documentation/arm/sa1100/graphicsmaster.rst
+++ /dev/null
@@ -1,60 +0,0 @@
-========================================
-ADS GraphicsMaster Single Board Computer
-========================================
-
-For more details, contact Applied Data Systems or see
-http://www.applieddata.net/products.html
-
-The original Linux support for this product has been provided by
-Nicolas Pitre <nico@fluxnic.net>. Continued development work by
-Woojung Huh <whuh@applieddata.net>
-
-Use 'make graphicsmaster_config' before any 'make config'.
-This will set up defaults for GraphicsMaster support.
-
-The kernel zImage is linked to be loaded and executed at 0xc0400000.
-
-Linux can be used with the ADS BootLoader that ships with the
-newer rev boards. See their documentation on how to load Linux.
-
-Supported peripherals
-=====================
-
-- SA1100 LCD frame buffer (8/16bpp...sort of)
-- SA1111 USB Master
-- on-board SMC 92C96 ethernet NIC
-- SA1100 serial port
-- flash memory access (MTD/JFFS)
-- pcmcia, compact flash
-- touchscreen(ucb1200)
-- ps/2 keyboard
-- console on LCD screen
-- serial ports (ttyS[0-2])
- - ttyS0 is default for serial console
-- Smart I/O (ADC, keypad, digital inputs, etc)
- See http://www.eurotech-inc.com/linux-sbc.asp for IOCTL documentation
- and example user space code. ps/2 keybd is multiplexed through this driver
-
-To do
-=====
-
-- everything else! :-)
-
-Notes
-=====
-
-- The flash on board is divided into 3 partitions. mtd0 is where
- the zImage is stored. It's been marked as read-only to keep you
- from blasting over the bootloader. :) mtd1 is
- for the ramdisk.gz image. mtd2 is user flash space and can be
- utilized for either JFFS or if you're feeling crazy, running ext2
- on top of it. If you're not using the ADS bootloader, you're
- welcome to blast over the mtd1 partition also.
-
-- 16bpp mode requires a different cable than what ships with the board.
- Contact ADS or look through the manual to wire your own. Currently,
- if you compile with 16bit mode support and switch into a lower bpp
- mode, the timing is off so the image is corrupted. This will be
- fixed soon.
-
-Any contribution can be sent to nico@fluxnic.net and will be greatly welcome!
diff --git a/Documentation/arm/sa1100/huw_webpanel.rst b/Documentation/arm/sa1100/huw_webpanel.rst
deleted file mode 100644
index 1dc7ccb165f0..000000000000
--- a/Documentation/arm/sa1100/huw_webpanel.rst
+++ /dev/null
@@ -1,21 +0,0 @@
-=======================
-Hoeft & Wessel Webpanel
-=======================
-
-The HUW_WEBPANEL is a product of the german company Hoeft & Wessel AG
-
-If you want more information, please visit
-http://www.hoeft-wessel.de
-
-To build the kernel::
-
- make huw_webpanel_config
- make oldconfig
- [accept all defaults]
- make zImage
-
-Mostly of the work is done by:
-Roman Jordan jor@hoeft-wessel.de
-Christoph Schulz schu@hoeft-wessel.de
-
-2000/12/18/
diff --git a/Documentation/arm/sa1100/index.rst b/Documentation/arm/sa1100/index.rst
index 68c2a280a745..c9aed43280ff 100644
--- a/Documentation/arm/sa1100/index.rst
+++ b/Documentation/arm/sa1100/index.rst
@@ -7,19 +7,7 @@ Intel StrongARM 1100
.. toctree::
:maxdepth: 1
- adsbitsy
assabet
- brutus
cerf
- freebird
- graphicsclient
- graphicsmaster
- huw_webpanel
- itsy
lart
- nanoengine
- pangolin
- pleb
serial_uart
- tifon
- yopy
diff --git a/Documentation/arm/sa1100/itsy.rst b/Documentation/arm/sa1100/itsy.rst
deleted file mode 100644
index f49896ba3ef1..000000000000
--- a/Documentation/arm/sa1100/itsy.rst
+++ /dev/null
@@ -1,47 +0,0 @@
-====
-Itsy
-====
-
-Itsy is a research project done by the Western Research Lab, and Systems
-Research Center in Palo Alto, CA. The Itsy project is one of several
-research projects at Compaq that are related to pocket computing.
-
-For more information, see:
-
- http://www.hpl.hp.com/downloads/crl/itsy/
-
-Notes on initial 2.4 Itsy support (8/27/2000) :
-
-The port was done on an Itsy version 1.5 machine with a daughtercard with
-64 Meg of DRAM and 32 Meg of Flash. The initial work includes support for
-serial console (to see what you're doing). No other devices have been
-enabled.
-
-To build, do a "make menuconfig" (or xmenuconfig) and select Itsy support.
-Disable Flash and LCD support. and then do a make zImage.
-Finally, you will need to cd to arch/arm/boot/tools and execute a make there
-to build the params-itsy program used to boot the kernel.
-
-In order to install the port of 2.4 to the itsy, You will need to set the
-configuration parameters in the monitor as follows::
-
- Arg 1:0x08340000, Arg2: 0xC0000000, Arg3:18 (0x12), Arg4:0
-
-Make sure the start-routine address is set to 0x00060000.
-
-Next, flash the params-itsy program to 0x00060000 ("p 1 0x00060000" in the
-flash menu) Flash the kernel in arch/arm/boot/zImage into 0x08340000
-("p 1 0x00340000"). Finally flash an initial ramdisk into 0xC8000000
-("p 2 0x0") We used ramdisk-2-30.gz from the 0.11 version directory on
-handhelds.org.
-
-The serial connection we established was at:
-
-8-bit data, no parity, 1 stop bit(s), 115200.00 b/s. in the monitor, in the
-params-itsy program, and in the kernel itself. This can be changed, but
-not easily. The monitor parameters are easily changed, the params program
-setup is assembly outl's, and the kernel is a configuration item specific to
-the itsy. (i.e. grep for CONFIG_SA1100_ITSY and you'll find where it is.)
-
-
-This should get you a properly booting 2.4 kernel on the itsy.
diff --git a/Documentation/arm/sa1100/nanoengine.rst b/Documentation/arm/sa1100/nanoengine.rst
deleted file mode 100644
index 47f1a14cf98a..000000000000
--- a/Documentation/arm/sa1100/nanoengine.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-==========
-nanoEngine
-==========
-
-"nanoEngine" is a SA1110 based single board computer from
-Bright Star Engineering Inc. See www.brightstareng.com/arm
-for more info.
-(Ref: Stuart Adams <sja@brightstareng.com>)
-
-Also visit Larry Doolittle's "Linux for the nanoEngine" site:
-http://www.brightstareng.com/arm/nanoeng.htm
diff --git a/Documentation/arm/sa1100/pangolin.rst b/Documentation/arm/sa1100/pangolin.rst
deleted file mode 100644
index f0c5c1618553..000000000000
--- a/Documentation/arm/sa1100/pangolin.rst
+++ /dev/null
@@ -1,29 +0,0 @@
-========
-Pangolin
-========
-
-Pangolin is a StrongARM 1110-based evaluation platform produced
-by Dialogue Technology (http://www.dialogue.com.tw/).
-It has EISA slots for ease of configuration with SDRAM/Flash
-memory card, USB/Serial/Audio card, Compact Flash card,
-PCMCIA/IDE card and TFT-LCD card.
-
-To compile for Pangolin, you must issue the following commands::
-
- make pangolin_config
- make oldconfig
- make zImage
-
-Supported peripherals
-=====================
-
-- SA1110 serial port (UART1/UART2/UART3)
-- flash memory access
-- compact flash driver
-- UDA1341 sound driver
-- SA1100 LCD controller for 800x600 16bpp TFT-LCD
-- MQ-200 driver for 800x600 16bpp TFT-LCD
-- Penmount(touch panel) driver
-- PCMCIA driver
-- SMC91C94 LAN driver
-- IDE driver (experimental)
diff --git a/Documentation/arm/sa1100/pleb.rst b/Documentation/arm/sa1100/pleb.rst
deleted file mode 100644
index d5b732967aa3..000000000000
--- a/Documentation/arm/sa1100/pleb.rst
+++ /dev/null
@@ -1,13 +0,0 @@
-====
-PLEB
-====
-
-The PLEB project was started as a student initiative at the School of
-Computer Science and Engineering, University of New South Wales to make a
-pocket computer capable of running the Linux Kernel.
-
-PLEB support has yet to be fully integrated.
-
-For more information, see:
-
- http://www.cse.unsw.edu.au
diff --git a/Documentation/arm/sa1100/tifon.rst b/Documentation/arm/sa1100/tifon.rst
deleted file mode 100644
index c26e910b9ea7..000000000000
--- a/Documentation/arm/sa1100/tifon.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-=====
-Tifon
-=====
-
-More info has to come...
-
-Contact: Peter Danielsson <peter.danielsson@era-t.ericsson.se>
diff --git a/Documentation/arm/sa1100/yopy.rst b/Documentation/arm/sa1100/yopy.rst
deleted file mode 100644
index 5b35a5f61a44..000000000000
--- a/Documentation/arm/sa1100/yopy.rst
+++ /dev/null
@@ -1,5 +0,0 @@
-====
-Yopy
-====
-
-See http://www.yopydeveloper.org for more.
--
2.20.1
^ permalink raw reply related
* [PATCH] Documentation/arm/samsung-s3c24xx: Remove stray U+FEFF character to fix title
From: Jonathan Neuschäfer @ 2019-08-08 16:48 UTC (permalink / raw)
To: linux-doc
Cc: linux-arm-kernel, Jonathan Neuschäfer, Jonathan Corbet,
Mauro Carvalho Chehab, linux-kernel
It seems a UTF-8 byte order mark (the least useful kind of BOM...) snuck
into the file and broke Sphinx's detection of the title line.
Besides making arm/samsung-s3c24xx/index.html look a little better, this
patch also confines the non-index pages in arm/samsung-s3c24xx to their
own table of contents.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
Documentation/arm/samsung-s3c24xx/index.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/arm/samsung-s3c24xx/index.rst b/Documentation/arm/samsung-s3c24xx/index.rst
index 5b8a7f9398d8..ccb951a0bedb 100644
--- a/Documentation/arm/samsung-s3c24xx/index.rst
+++ b/Documentation/arm/samsung-s3c24xx/index.rst
@@ -1,6 +1,6 @@
.. SPDX-License-Identifier: GPL-2.0
-==========================
+==========================
Samsung S3C24XX SoC Family
==========================
--
2.20.1
^ permalink raw reply related
* [PATCH] Documentation: crypto: crypto_engine: Fix Sphinx warning
From: Jonathan Neuschäfer @ 2019-08-08 16:30 UTC (permalink / raw)
To: linux-doc
Cc: Jonathan Neuschäfer, Herbert Xu, David S. Miller,
Jonathan Corbet, linux-crypto, linux-kernel
This fixes the following Sphinx warning:
Documentation/crypto/crypto_engine.rst:2:
WARNING: Explicit markup ends without a blank line; unexpected unindent.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
Documentation/crypto/crypto_engine.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/crypto/crypto_engine.rst b/Documentation/crypto/crypto_engine.rst
index 236c674d6897..3baa23c2cd08 100644
--- a/Documentation/crypto/crypto_engine.rst
+++ b/Documentation/crypto/crypto_engine.rst
@@ -1,4 +1,5 @@
.. SPDX-License-Identifier: GPL-2.0
+
Crypto Engine
=============
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v7 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst
From: Szabolcs Nagy @ 2019-08-08 16:30 UTC (permalink / raw)
To: Catalin Marinas, linux-arm-kernel@lists.infradead.org
Cc: nd, Vincenzo Frascino, Will Deacon, Andrey Konovalov,
Kevin Brodsky, linux-doc@vger.kernel.org,
linux-arch@vger.kernel.org, Dave Hansen
In-Reply-To: <20190807155321.9648-2-catalin.marinas@arm.com>
On 07/08/2019 16:53, Catalin Marinas wrote:
> From: Vincenzo Frascino <vincenzo.frascino@arm.com>
>
> On arm64 the TCR_EL1.TBI0 bit has been always enabled hence
> the userspace (EL0) is allowed to set a non-zero value in the
> top byte but the resulting pointers are not allowed at the
> user-kernel syscall ABI boundary.
>
> With the relaxed ABI proposed through this document, it is now possible
> to pass tagged pointers to the syscalls, when these pointers are in
> memory ranges obtained by an anonymous (MAP_ANONYMOUS) mmap().
description needs to be updated not to restrict tags
to anon mmap.
> +3. AArch64 Tagged Address ABI Exceptions
> +-----------------------------------------
> +
> +The behaviour described in section 2, with particular reference to the
> +acceptance by the syscalls of any valid tagged pointer, is not applicable
> +to the following cases:
> +
> +- mmap() addr parameter.
> +
> +- mremap() new_address parameter.
> +
> +- prctl(PR_SET_MM, ``*``, ...) other than arg2 PR_SET_MM_MAP and
> + PR_SET_MM_MAP_SIZE.
> +
> +- prctl(PR_SET_MM, PR_SET_MM_MAP{,_SIZE}, ...) struct prctl_mm_map fields.
> +
> +Any attempt to use non-zero tagged pointers will lead to undefined
> +behaviour.
i think that brk may be affected too by whatever that's
causing problems in mmap.
otherwise the text looks good to me.
^ permalink raw reply
* Re: [PATCH v7 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst
From: Dave Martin @ 2019-08-08 16:27 UTC (permalink / raw)
To: Dave Hansen
Cc: Catalin Marinas, linux-arm-kernel, linux-arch, linux-doc,
Szabolcs Nagy, Andrey Konovalov, Kevin Brodsky, Will Deacon,
Vincenzo Frascino
In-Reply-To: <826a9ace-feac-c019-843e-07e23c9fd46c@intel.com>
On Wed, Aug 07, 2019 at 01:38:16PM -0700, Dave Hansen wrote:
[Random comments below on a couple of points]
> On 8/7/19 8:53 AM, Catalin Marinas wrote:
> > +- mmap() done by the process itself (or its parent), where either:
> > +
> > + - flags have the **MAP_ANONYMOUS** bit set
> > + - the file descriptor refers to a regular file (including those returned
> > + by memfd_create()) or **/dev/zero**
>
> What's a "regular file"? ;)
A file, as distinct from device nodes, sockets, symlinks etc.
I think this is fairly standard UNIX terminology, even though it sounds
vague:
From glibc's <bits/stat.h>:
#define __S_IFREG 0100000 /* Regular file. */
Or for POSIX test (a.k.a. "[")
-f file
True if file exists and is a regular file.
Using memfd_create() or opening /dev/zero doesn't yield a regular file
though, so perhaps those should be a separate bullet.
[...]
> > +The AArch64 Tagged Address ABI is an opt-in feature and an application can
> > +control it via **prctl()** as follows:
> > +
> > +- **PR_SET_TAGGED_ADDR_CTRL**: enable or disable the AArch64 Tagged Address
> > + ABI for the calling process.
> > +
> > + The (unsigned int) arg2 argument is a bit mask describing the control mode
> > + used:
> > +
> > + - **PR_TAGGED_ADDR_ENABLE**: enable AArch64 Tagged Address ABI. Default
> > + status is disabled.
> > +
> > + The arguments arg3, arg4, and arg5 are ignored.
>
> For previous prctl()'s, we've found that it's best to require that the
> unused arguments be 0. Without that, apps are free to put garbage
> there, which makes extending the prctl to use other arguments impossible
> in the future.
Because arg2 is already a mask of flags with some flags unallocated,
we can add a new flag for ABI extensions.
If arg3 is used someday, it may or may not be natural for 0 to mean
"default". Enabling this argument with an explicit flag in arg2 may
be cleaner than mangling the semantics of arg3 so that 0 can have
the right meaning.
Avoiding redundant 0 arguments also allows userspace to take advantage
of the glibc's variadic prototype for prctl() for example.
Not a huge deal, but that was my rationale anyway.
> Also, shouldn't this be converted over to an arch_prctl()?
Most arch-specific prctls seem to use prctl(), and arm64 already has a
few there.
arch_prctl() is x86-specific. I don't know the history.
[...]
Cheers
---Dave
^ permalink raw reply
* Re: [PATCH v7 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst
From: Szabolcs Nagy @ 2019-08-08 16:20 UTC (permalink / raw)
To: Dave Hansen, Catalin Marinas,
linux-arm-kernel@lists.infradead.org
Cc: nd, Vincenzo Frascino, Will Deacon, Andrey Konovalov,
Kevin Brodsky, linux-doc@vger.kernel.org,
linux-arch@vger.kernel.org
In-Reply-To: <826a9ace-feac-c019-843e-07e23c9fd46c@intel.com>
On 07/08/2019 21:38, Dave Hansen wrote:
> On 8/7/19 8:53 AM, Catalin Marinas wrote:
>> +- mmap() done by the process itself (or its parent), where either:
>> +
>> + - flags have the **MAP_ANONYMOUS** bit set
>> + - the file descriptor refers to a regular file (including those returned
>> + by memfd_create()) or **/dev/zero**
>
> What's a "regular file"? ;)
i'd expect the posix definition.
in posix "File types include regular file, character
special file, block special file, FIFO special file,
symbolic link, socket, and directory. Other types of
files may be supported by the implementation."
where regular file is "A file that is a randomly
accessible sequence of bytes, with no further
structure imposed by the system."
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_323
^ permalink raw reply
* Re: [PATCH 9/9] arm64: Retrieve stolen time as paravirtualized guest
From: Marc Zyngier @ 2019-08-08 15:49 UTC (permalink / raw)
To: Steven Price
Cc: Catalin Marinas, Paolo Bonzini, Radim Krčmář,
Russell King, Will Deacon, James Morse, Julien Thierry,
Suzuki K Pouloze, kvm, kvmarm, linux-arm-kernel, linux-doc,
linux-kernel
In-Reply-To: <dc8a1e56-7b52-cc8f-265d-27eb5f458613@arm.com>
On 08/08/2019 16:29, Steven Price wrote:
> On 04/08/2019 10:53, Marc Zyngier wrote:
>> On Fri, 2 Aug 2019 15:50:17 +0100
>> Steven Price <steven.price@arm.com> wrote:
>>
>>> Enable paravirtualization features when running under a hypervisor
>>> supporting the PV_TIME_ST hypercall.
>>>
>>> For each (v)CPU, we ask the hypervisor for the location of a shared
>>> page which the hypervisor will use to report stolen time to us. We set
>>> pv_time_ops to the stolen time function which simply reads the stolen
>>> value from the shared page for a VCPU. We guarantee single-copy
>>> atomicity using READ_ONCE which means we can also read the stolen
>>> time for another VCPU than the currently running one while it is
>>> potentially being updated by the hypervisor.
>>>
>>> Signed-off-by: Steven Price <steven.price@arm.com>
>>> ---
>>> arch/arm64/kernel/Makefile | 1 +
>>> arch/arm64/kernel/kvm.c | 155 +++++++++++++++++++++++++++++++++++++
[...]
>>> +static int __init kvm_guest_init(void)
>>> +{
>>> + int ret = 0;
>>> +
>>> + if (!has_kvm_steal_clock())
>>> + return 0;
>>> +
>>> + ret = kvm_arm_init_stolen_time();
>>> + if (ret)
>>> + return ret;
>>> +
>>> + pv_ops.time.steal_clock = kvm_steal_clock;
>>> +
>>> + static_key_slow_inc(¶virt_steal_enabled);
>>> + if (steal_acc)
>>> + static_key_slow_inc(¶virt_steal_rq_enabled);
>>> +
>>> + pr_info("using stolen time PV\n");
>>> +
>>> + return 0;
>>> +}
>>> +early_initcall(kvm_guest_init);
>>
>> Is there any reason why we wouldn't directly call into this rather than
>> using an initcall?
>
> I'm not sure where the direct call would go - any pointers?
I'd be temped to say arch/arm64/kernel/time.c:time_init(), provided that
there is no issue with the CPU hotplug lock (I remember hitting that a
while ago).
M.
--
Jazz is not dead, it just smells funny...
^ permalink raw reply
* Re: [PATCH 0/6] hwspinlock: allow sharing of hwspinlocks
From: Bjorn Andersson @ 2019-08-08 15:37 UTC (permalink / raw)
To: Fabien DESSENNE
Cc: Suman Anna, Ohad Ben-Cohen, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre TORGUE, Jonathan Corbet,
linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
Benjamin GAIGNARD
In-Reply-To: <d8d4a172-ec18-a758-d994-8e05bb6a1f48@st.com>
On Thu 08 Aug 05:52 PDT 2019, Fabien DESSENNE wrote:
>
> On 07/08/2019 6:19 PM, Suman Anna wrote:
> > Hi Fabien,
> >
> > On 8/7/19 3:39 AM, Fabien DESSENNE wrote:
> >> Hi
> >>
> >> On 06/08/2019 11:30 PM, Suman Anna wrote:
> >>> On 8/6/19 1:21 PM, Bjorn Andersson wrote:
> >>>> On Tue 06 Aug 10:38 PDT 2019, Suman Anna wrote:
> >>>>
> >>>>> Hi Fabien,
> >>>>>
> >>>>> On 8/5/19 12:46 PM, Bjorn Andersson wrote:
> >>>> I agree that we shouldn't specify this property in DT - if anything it
> >>>> should be a variant of the API.
> >>
> >> If we decide to add a 'shared' API, then, what about the generic regmap
> >> driver?
> >>
> >> In the context of above example1, this would require to update the
> >> regmap driver.
> >>
> >> But would this be acceptable for any driver using syscon/regmap?
> >>
> >>
> >> I think it is better to keep the existing API (modifying it so it always
> >> allows
> >>
> >> hwlocks sharing, so no need for bindings update) than adding another API.
> > For your usecases, you would definitely need the syscon/regmap behavior
> > to be shared right. Whether we introduce a 'shared' API or an
> > 'exclusive' API and change the current API behavior to shared, it is
> > definitely a case-by-case usage scenario for the existing drivers and
> > usage right. The main contention point is what to do with the
> > unprotected usecases like Bjorn originally pointed out.
>
> OK, I see : the hwspinlock framework does not offer any lock protection
> with the RAW/IN_ATOMIC modes.
> This is an issue if several different 'local' drivers try to get a
> shared lock in the same time.
> And this is a personal problem since I need to use shared locks in
> ...atomic mode.
>
Why can't you use HWLOCK_IRQSTATE in this mode?
> I have tried to see how it is possible to put a constraint on the
> callers, just like this is documented for the RAW mode which is:
> "Caution: If the mode is HWLOCK_RAW, that means user must protect
> the routine
> of getting hardware lock with mutex or spinlock.."
> I do not think that it is acceptable to ask several drivers to share a
> common mutex/spinlock for shared locks.
No it's not.
> But I think about another option: the driver implementing the trylock
> ops may offer such protection. This is the case if the driver returns
> "busy" if the lock is already taken, not only by the remote processor,
> but also by the local host.
>
I think it's typical for hwspinlock hardware to not be able to
distinguish between different clients within Linux, so we would need to
wrap the usage in some construct that ensures mutual exclusion in Linux
- like a spinlock...
> So what do you think about adding such a documentation note :
> "Caution : the HWLOCK_RAW / HWLOCK_IN_ATOMIC modes shall not be used
> with shared locks unless the hwspinlock driver supports local lock
> protection"
>
But having local lock protection in the hwspinlock driver would defeat
the purpose of HWLOCK_RAW.
Also this kind of warning will at best be consumed by the client driver
authors, it will not be read by the dts authors.
Regards,
Bjorn
> Optionally, we may add a "local_lock_protection" flag in the
> hwspinlock_device struct, set by the driver before it calls
> hwspin_lock_register().
> This flag can then be checked by hwspinlock core to allow/deny use of
> shared locks in the raw/atomic modes.
>
> Let me know what you think about it.
>
> BR
>
> Fabien
>
> >
> > regards
> > Suman
> >
> >>
> >>
> >>>>> If you are sharing a hwlock on the Linux side, surely your driver should
> >>>>> be aware that it is a shared lock. The tag can be set during the first
> >>>>> request API, and you look through both tags when giving out a handle.
> >>>>>
> >>>> Why would the driver need to know about it?
> >>> Just the semantics if we were to support single user vs multiple users
> >>> on Linux-side to even get a handle. Your point is that this may be moot
> >>> since we have protection anyway other than the raw cases. But we need to
> >>> be able to have the same API work across all cases.
> >>>
> >>> So far, it had mostly been that there would be one user on Linux
> >>> competing with other equivalent peer entities on different processors.
> >>> It is not common to have multiple users since these protection schemes
> >>> are usually needed only at the lowest levels of a stack, so the
> >>> exclusive handle stuff had been sufficient.
> >>>
> >>>>> Obviously, the hwspin_lock_request() API usage semantics always had the
> >>>>> implied additional need for communicating the lock id to the other peer
> >>>>> entity, so a realistic usage is most always the specific API variant. I
> >>>>> doubt this API would be of much use for the shared driver usage. This
> >>>>> also implies that the client user does not care about specifying a lock
> >>>>> in DT.
> >>>>>
> >>>> Afaict if the lock are shared then there shouldn't be a problem with
> >>>> some clients using the request API and others request_specific(). As any
> >>>> collisions would simply mean that there are more contention on the lock.
> >>>>
> >>>> With the current exclusive model that is not possible and the success of
> >>>> the request_specific will depend on probe order.
> >>>>
> >>>> But perhaps it should be explicitly prohibited to use both APIs on the
> >>>> same hwspinlock instance?
> >>> Yeah, they are meant to be complimentary usage, though I doubt we will
> >>> ever have any realistic users for the generic API if we haven't had a
> >>> usage so far. I had posted a concept of reserved locks long back [1] to
> >>> keep away certain locks from the generic requestor, but dropped it since
> >>> we did not have an actual use-case needing it.
> >>>
> >>> regards
> >>> Suman
> >>>
> >>> [1] https://lwn.net/Articles/611944/
^ permalink raw reply
* Re: [PATCH 9/9] arm64: Retrieve stolen time as paravirtualized guest
From: Steven Price @ 2019-08-08 15:29 UTC (permalink / raw)
To: Marc Zyngier
Cc: Catalin Marinas, Paolo Bonzini, Radim Krčmář,
Russell King, Will Deacon, James Morse, Julien Thierry,
Suzuki K Pouloze, kvm, kvmarm, linux-arm-kernel, linux-doc,
linux-kernel
In-Reply-To: <20190804105353.5e9824dc@why>
On 04/08/2019 10:53, Marc Zyngier wrote:
> On Fri, 2 Aug 2019 15:50:17 +0100
> Steven Price <steven.price@arm.com> wrote:
>
>> Enable paravirtualization features when running under a hypervisor
>> supporting the PV_TIME_ST hypercall.
>>
>> For each (v)CPU, we ask the hypervisor for the location of a shared
>> page which the hypervisor will use to report stolen time to us. We set
>> pv_time_ops to the stolen time function which simply reads the stolen
>> value from the shared page for a VCPU. We guarantee single-copy
>> atomicity using READ_ONCE which means we can also read the stolen
>> time for another VCPU than the currently running one while it is
>> potentially being updated by the hypervisor.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> arch/arm64/kernel/Makefile | 1 +
>> arch/arm64/kernel/kvm.c | 155 +++++++++++++++++++++++++++++++++++++
>
> nit: Why not using paravirt.c, which clearly states what it does? The
> alternative would be to name it kvm-pv.c.
I can move it to paravirt.c - seems reasonable.
>> include/linux/cpuhotplug.h | 1 +
>> 3 files changed, 157 insertions(+)
>> create mode 100644 arch/arm64/kernel/kvm.c
>>
>> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
>> index 478491f07b4f..eb36edf9b930 100644
>> --- a/arch/arm64/kernel/Makefile
>> +++ b/arch/arm64/kernel/Makefile
>> @@ -63,6 +63,7 @@ obj-$(CONFIG_CRASH_CORE) += crash_core.o
>> obj-$(CONFIG_ARM_SDE_INTERFACE) += sdei.o
>> obj-$(CONFIG_ARM64_SSBD) += ssbd.o
>> obj-$(CONFIG_ARM64_PTR_AUTH) += pointer_auth.o
>> +obj-$(CONFIG_PARAVIRT) += kvm.o
>>
>> obj-y += vdso/ probes/
>> obj-$(CONFIG_COMPAT_VDSO) += vdso32/
>> diff --git a/arch/arm64/kernel/kvm.c b/arch/arm64/kernel/kvm.c
>> new file mode 100644
>> index 000000000000..245398c79dae
>> --- /dev/null
>> +++ b/arch/arm64/kernel/kvm.c
>> @@ -0,0 +1,155 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (C) 2019 Arm Ltd.
>> +
>> +#define pr_fmt(fmt) "kvmarm-pv: " fmt
>> +
>> +#include <linux/arm-smccc.h>
>> +#include <linux/cpuhotplug.h>
>> +#include <linux/io.h>
>> +#include <linux/printk.h>
>> +#include <linux/psci.h>
>> +#include <linux/reboot.h>
>> +#include <linux/slab.h>
>> +
>> +#include <asm/paravirt.h>
>> +#include <asm/pvclock-abi.h>
>> +#include <asm/smp_plat.h>
>> +
>> +struct kvmarm_stolen_time_region {
>> + struct pvclock_vcpu_stolen_time_info *kaddr;
>> +};
>> +
>> +static DEFINE_PER_CPU(struct kvmarm_stolen_time_region, stolen_time_region);
>> +
>> +static bool steal_acc = true;
>> +static int __init parse_no_stealacc(char *arg)
>> +{
>> + steal_acc = false;
>> + return 0;
>> +}
>> +early_param("no-steal-acc", parse_no_stealacc);
>> +
>> +/* return stolen time in ns by asking the hypervisor */
>> +static u64 kvm_steal_clock(int cpu)
>> +{
>> + struct kvmarm_stolen_time_region *reg;
>> +
>> + reg = per_cpu_ptr(&stolen_time_region, cpu);
>> + if (!reg->kaddr) {
>> + pr_warn_once("stolen time enabled but not configured for cpu %d\n",
>> + cpu);
>> + return 0;
>> + }
>> +
>> + return le64_to_cpu(READ_ONCE(reg->kaddr->stolen_time));
>> +}
>> +
>> +static int disable_stolen_time_current_cpu(void)
>> +{
>> + struct kvmarm_stolen_time_region *reg;
>> +
>> + reg = this_cpu_ptr(&stolen_time_region);
>> + if (!reg->kaddr)
>> + return 0;
>> +
>> + memunmap(reg->kaddr);
>> + memset(reg, 0, sizeof(*reg));
>> +
>> + return 0;
>> +}
>> +
>> +static int stolen_time_dying_cpu(unsigned int cpu)
>> +{
>> + return disable_stolen_time_current_cpu();
>> +}
>> +
>> +static int init_stolen_time_cpu(unsigned int cpu)
>> +{
>> + struct kvmarm_stolen_time_region *reg;
>> + struct arm_smccc_res res;
>> +
>> + reg = this_cpu_ptr(&stolen_time_region);
>> +
>> + if (reg->kaddr)
>> + return 0;
>
> Can this actually happen? It'd take two CPU_UP calls from the HP
> notifiers to get in that situation...
Yes, something would have to be very broken for that to happen - I'll
remove this check.
>> +
>> + arm_smccc_1_1_invoke(ARM_SMCCC_HV_PV_TIME_ST, &res);
>> +
>> + if ((long)res.a0 < 0)
>> + return -EINVAL;
>> +
>> + reg->kaddr = memremap(res.a0,
>> + sizeof(struct pvclock_vcpu_stolen_time_info),
>> + MEMREMAP_WB);
>> +
>> + if (reg->kaddr == NULL) {
>> + pr_warn("Failed to map stolen time data structure\n");
>> + return -EINVAL;
>
> -ENOMEM is the expected return code.
Ok
>> + }
>> +
>> + if (le32_to_cpu(reg->kaddr->revision) != 0 ||
>> + le32_to_cpu(reg->kaddr->attributes) != 0) {
>> + pr_warn("Unexpected revision or attributes in stolen time data\n");
>> + return -ENXIO;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int kvm_arm_init_stolen_time(void)
>> +{
>> + int ret;
>> +
>> + ret = cpuhp_setup_state(CPUHP_AP_ARM_KVMPV_STARTING,
>> + "hypervisor/kvmarm/pv:starting",
>> + init_stolen_time_cpu, stolen_time_dying_cpu);
>> + if (ret < 0)
>> + return ret;
>> + return 0;
>> +}
>> +
>> +static bool has_kvm_steal_clock(void)
>> +{
>> + struct arm_smccc_res res;
>> +
>> + /* To detect the presence of PV time support we require SMCCC 1.1+ */
>> + if (psci_ops.smccc_version < SMCCC_VERSION_1_1)
>> + return false;
>> +
>> + arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
>> + ARM_SMCCC_HV_PV_FEATURES, &res);
>> +
>> + if (res.a0 != SMCCC_RET_SUCCESS)
>> + return false;
>> +
>> + arm_smccc_1_1_invoke(ARM_SMCCC_HV_PV_FEATURES,
>> + ARM_SMCCC_HV_PV_TIME_ST, &res);
>> +
>> + if (res.a0 != SMCCC_RET_SUCCESS)
>> + return false;
>> +
>> + return true;
>> +}
>> +
>> +static int __init kvm_guest_init(void)
>> +{
>> + int ret = 0;
>> +
>> + if (!has_kvm_steal_clock())
>> + return 0;
>> +
>> + ret = kvm_arm_init_stolen_time();
>> + if (ret)
>> + return ret;
>> +
>> + pv_ops.time.steal_clock = kvm_steal_clock;
>> +
>> + static_key_slow_inc(¶virt_steal_enabled);
>> + if (steal_acc)
>> + static_key_slow_inc(¶virt_steal_rq_enabled);
>> +
>> + pr_info("using stolen time PV\n");
>> +
>> + return 0;
>> +}
>> +early_initcall(kvm_guest_init);
>
> Is there any reason why we wouldn't directly call into this rather than
> using an initcall?
I'm not sure where the direct call would go - any pointers?
Thanks,
Steve
>> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
>> index 068793a619ca..89d75edb5750 100644
>> --- a/include/linux/cpuhotplug.h
>> +++ b/include/linux/cpuhotplug.h
>> @@ -136,6 +136,7 @@ enum cpuhp_state {
>> /* Must be the last timer callback */
>> CPUHP_AP_DUMMY_TIMER_STARTING,
>> CPUHP_AP_ARM_XEN_STARTING,
>> + CPUHP_AP_ARM_KVMPV_STARTING,
>> CPUHP_AP_ARM_CORESIGHT_STARTING,
>> CPUHP_AP_ARM64_ISNDEP_STARTING,
>> CPUHP_AP_SMPCFD_DYING,
>
>
> Thanks,
>
> M.
>
^ permalink raw reply
* Re: [PATCH v15 05/13] clk: ingenic: Add driver for the TCU clocks
From: Stephen Boyd @ 2019-08-08 14:48 UTC (permalink / raw)
To: Arnd Bergmann, Daniel Lezcano, James Hogan, Jason Cooper,
Jonathan Corbet, Lee Jones, Marc Zyngier, Mark Rutland,
Michael Turquette, Paul Burton, Paul Cercueil, Ralf Baechle,
Rob Herring, Thomas Gleixner
Cc: devicetree, linux-kernel, linux-doc, linux-mips, linux-clk, od,
Mathieu Malaterre, Paul Cercueil, Artur Rojek
In-Reply-To: <20190724171615.20774-6-paul@crapouillou.net>
Quoting Paul Cercueil (2019-07-24 10:16:07)
> Add driver to support the clocks provided by the Timer/Counter Unit
> (TCU) of the JZ47xx SoCs from Ingenic.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> Tested-by: Mathieu Malaterre <malat@debian.org>
> Tested-by: Artur Rojek <contact@artur-rojek.eu>
> ---
Acked-by: Stephen Boyd <sboyd@kernel.org>
^ 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