* [PATCH v3 01/33] docs: aoe: convert docs to ReST and rename to *.rst
From: Mauro Carvalho Chehab @ 2019-06-09 2:26 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <cover.1560045490.git.mchehab+samsung@kernel.org>
There are only two files within Documentation/aoe dir that are
documentation. The remaining ones are examples and shell
scripts.
Convert the two AoE files to ReST format, and add the others
as literal, as they're part of the documentation.
At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/aoe/{aoe.txt => aoe.rst} | 63 +++++++++++++-----------
Documentation/aoe/examples.rst | 23 +++++++++
Documentation/aoe/index.rst | 19 +++++++
Documentation/aoe/{todo.txt => todo.rst} | 3 ++
Documentation/aoe/udev.txt | 2 +-
5 files changed, 81 insertions(+), 29 deletions(-)
rename Documentation/aoe/{aoe.txt => aoe.rst} (79%)
create mode 100644 Documentation/aoe/examples.rst
create mode 100644 Documentation/aoe/index.rst
rename Documentation/aoe/{todo.txt => todo.rst} (98%)
diff --git a/Documentation/aoe/aoe.txt b/Documentation/aoe/aoe.rst
similarity index 79%
rename from Documentation/aoe/aoe.txt
rename to Documentation/aoe/aoe.rst
index c71487d399d1..58747ecec71d 100644
--- a/Documentation/aoe/aoe.txt
+++ b/Documentation/aoe/aoe.rst
@@ -1,3 +1,6 @@
+Introduction
+============
+
ATA over Ethernet is a network protocol that provides simple access to
block storage on the LAN.
@@ -22,7 +25,8 @@ document the use of the driver and are not necessary if you install
the aoetools.
-CREATING DEVICE NODES
+Creating Device Nodes
+=====================
Users of udev should find the block device nodes created
automatically, but to create all the necessary device nodes, use the
@@ -38,7 +42,8 @@ CREATING DEVICE NODES
confusing when an AoE device is not present the first time the a
command is run but appears a second later.
-USING DEVICE NODES
+Using Device Nodes
+==================
"cat /dev/etherd/err" blocks, waiting for error diagnostic output,
like any retransmitted packets.
@@ -55,7 +60,7 @@ USING DEVICE NODES
by sysfs counterparts. Using the commands in aoetools insulates
users from these implementation details.
- The block devices are named like this:
+ The block devices are named like this::
e{shelf}.{slot}
e{shelf}.{slot}p{part}
@@ -64,7 +69,8 @@ USING DEVICE NODES
first shelf (shelf address zero). That's the whole disk. The first
partition on that disk would be "e0.2p1".
-USING SYSFS
+Using sysfs
+===========
Each aoe block device in /sys/block has the extra attributes of
state, mac, and netif. The state attribute is "up" when the device
@@ -78,29 +84,29 @@ USING SYSFS
There is a script in this directory that formats this information in
a convenient way. Users with aoetools should use the aoe-stat
- command.
+ command::
- root@makki root# sh Documentation/aoe/status.sh
- e10.0 eth3 up
- e10.1 eth3 up
- e10.2 eth3 up
- e10.3 eth3 up
- e10.4 eth3 up
- e10.5 eth3 up
- e10.6 eth3 up
- e10.7 eth3 up
- e10.8 eth3 up
- e10.9 eth3 up
- e4.0 eth1 up
- e4.1 eth1 up
- e4.2 eth1 up
- e4.3 eth1 up
- e4.4 eth1 up
- e4.5 eth1 up
- e4.6 eth1 up
- e4.7 eth1 up
- e4.8 eth1 up
- e4.9 eth1 up
+ root@makki root# sh Documentation/aoe/status.sh
+ e10.0 eth3 up
+ e10.1 eth3 up
+ e10.2 eth3 up
+ e10.3 eth3 up
+ e10.4 eth3 up
+ e10.5 eth3 up
+ e10.6 eth3 up
+ e10.7 eth3 up
+ e10.8 eth3 up
+ e10.9 eth3 up
+ e4.0 eth1 up
+ e4.1 eth1 up
+ e4.2 eth1 up
+ e4.3 eth1 up
+ e4.4 eth1 up
+ e4.5 eth1 up
+ e4.6 eth1 up
+ e4.7 eth1 up
+ e4.8 eth1 up
+ e4.9 eth1 up
Use /sys/module/aoe/parameters/aoe_iflist (or better, the driver
option discussed below) instead of /dev/etherd/interfaces to limit
@@ -113,12 +119,13 @@ USING SYSFS
for this purpose. You can also directly use the
/dev/etherd/discover special file described above.
-DRIVER OPTIONS
+Driver Options
+==============
There is a boot option for the built-in aoe driver and a
corresponding module parameter, aoe_iflist. Without this option,
all network interfaces may be used for ATA over Ethernet. Here is a
- usage example for the module parameter.
+ usage example for the module parameter::
modprobe aoe_iflist="eth1 eth3"
diff --git a/Documentation/aoe/examples.rst b/Documentation/aoe/examples.rst
new file mode 100644
index 000000000000..91f3198e52c1
--- /dev/null
+++ b/Documentation/aoe/examples.rst
@@ -0,0 +1,23 @@
+Example of udev rules
+---------------------
+
+ .. include:: udev.txt
+ :literal:
+
+Example of udev install rules script
+------------------------------------
+
+ .. literalinclude:: udev-install.sh
+ :language: shell
+
+Example script to get status
+----------------------------
+
+ .. literalinclude:: status.sh
+ :language: shell
+
+Example of AoE autoload script
+------------------------------
+
+ .. literalinclude:: autoload.sh
+ :language: shell
diff --git a/Documentation/aoe/index.rst b/Documentation/aoe/index.rst
new file mode 100644
index 000000000000..4394b9b7913c
--- /dev/null
+++ b/Documentation/aoe/index.rst
@@ -0,0 +1,19 @@
+:orphan:
+
+=======================
+ATA over Ethernet (AoE)
+=======================
+
+.. toctree::
+ :maxdepth: 1
+
+ aoe
+ todo
+ examples
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/aoe/todo.txt b/Documentation/aoe/todo.rst
similarity index 98%
rename from Documentation/aoe/todo.txt
rename to Documentation/aoe/todo.rst
index c09dfad4aed8..dea8db5a33e1 100644
--- a/Documentation/aoe/todo.txt
+++ b/Documentation/aoe/todo.rst
@@ -1,3 +1,6 @@
+TODO
+====
+
There is a potential for deadlock when allocating a struct sk_buff for
data that needs to be written out to aoe storage. If the data is
being written from a dirty page in order to free that page, and if
diff --git a/Documentation/aoe/udev.txt b/Documentation/aoe/udev.txt
index 1f06daf03f5b..54feda5a0772 100644
--- a/Documentation/aoe/udev.txt
+++ b/Documentation/aoe/udev.txt
@@ -11,7 +11,7 @@
# udev_rules="/etc/udev/rules.d/"
# bash# ls /etc/udev/rules.d/
# 10-wacom.rules 50-udev.rules
-# bash# cp /path/to/linux-2.6.xx/Documentation/aoe/udev.txt \
+# bash# cp /path/to/linux/Documentation/aoe/udev.txt \
# /etc/udev/rules.d/60-aoe.rules
#
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Pavel Machek @ 2019-06-08 20:52 UTC (permalink / raw)
To: Dave Hansen
Cc: Peter Zijlstra, Yu-cheng Yu, x86, H. Peter Anvin, Thomas Gleixner,
Ingo Molnar, linux-kernel, linux-doc, linux-mm, linux-arch,
linux-api, Arnd Bergmann, Andy Lutomirski, Balbir Singh,
Borislav Petkov, Cyrill Gorcunov, Dave Hansen,
Eugene Syromiatnikov, Florian Weimer, H.J. Lu, Jann Horn,
Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Randy Dunlap, Ravi V. Shankar, Vedvyas Shanbhogue,
Dave Martin
In-Reply-To: <b3de4110-5366-fdc7-a960-71dea543a42f@intel.com>
Hi!
> > I've no idea what the kernel should do; since you failed to answer the
> > question what happens when you point this to garbage.
> >
> > Does it then fault or what?
>
> Yeah, I think you'll fault with a rather mysterious CR2 value since
> you'll go look at the instruction that faulted and not see any
> references to the CR2 value.
>
> I think this new MSR probably needs to get included in oops output when
> CET is enabled.
>
> Why don't we require that a VMA be in place for the entire bitmap?
> Don't we need a "get" prctl function too in case something like a JIT is
> running and needs to find the location of this bitmap to set bits itself?
>
> Or, do we just go whole-hog and have the kernel manage the bitmap
> itself. Our interface here could be:
>
> prctl(PR_MARK_CODE_AS_LEGACY, start, size);
>
> and then have the kernel allocate and set the bitmap for those code
> locations.
For the record, that sounds like a better interface than userspace knowing
about the bitmap formats...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH v2 00/22] Some documentation fixes
From: Jonathan Corbet @ 2019-06-08 19:44 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, netdev, bpf
In-Reply-To: <20190607154430.4879976d@coco.lan>
On Fri, 7 Jun 2019 15:44:30 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> After doing that, there are 17 patches yet to be applied. Two new
> patches are now needed too, due to vfs.txt -> vfs.rst and
> pci.txt -> pci.rst renames.
OK, I've applied the set, minus those that had been picked up elsewhere.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v3 20/20] docs: pci: fix broken links due to conversion from pci.txt to pci.rst
From: Paul E. McKenney @ 2019-06-08 15:37 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Alan Stern, Andrea Parri, Will Deacon,
Peter Zijlstra, Boqun Feng, Nicholas Piggin, David Howells,
Jade Alglave, Luc Maranget, Akira Yokosawa, Daniel Lustig,
Don Brace, James E.J. Bottomley, Martin K. Petersen, linux-arch,
esc.storagedev, linux-scsi
In-Reply-To: <780cb6c2dfe860873394675df6580765ea5a2680.1559933665.git.mchehab+samsung@kernel.org>
On Fri, Jun 07, 2019 at 03:54:36PM -0300, Mauro Carvalho Chehab wrote:
> Some documentation files were still pointing to the old place.
>
> Fixes: 229b4e0728e0 ("Documentation: PCI: convert pci.txt to reST")
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Paul E. McKenney <paulmck@linux.ibm.com>
> ---
> Documentation/memory-barriers.txt | 2 +-
> Documentation/translations/ko_KR/memory-barriers.txt | 2 +-
> drivers/scsi/hpsa.c | 4 ++--
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> index f70ebcdfe592..f4170aae1d75 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -548,7 +548,7 @@ There are certain things that the Linux kernel memory barriers do not guarantee:
>
> [*] For information on bus mastering DMA and coherency please read:
>
> - Documentation/PCI/pci.txt
> + Documentation/PCI/pci.rst
> Documentation/DMA-API-HOWTO.txt
> Documentation/DMA-API.txt
>
> diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
> index db0b9d8619f1..07725b1df002 100644
> --- a/Documentation/translations/ko_KR/memory-barriers.txt
> +++ b/Documentation/translations/ko_KR/memory-barriers.txt
> @@ -569,7 +569,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE
>
> [*] 버스 마스터링 DMA 와 일관성에 대해서는 다음을 참고하시기 바랍니다:
>
> - Documentation/PCI/pci.txt
> + Documentation/PCI/pci.rst
> Documentation/DMA-API-HOWTO.txt
> Documentation/DMA-API.txt
>
> diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> index 1bef1da273c2..53df6f7dd3f9 100644
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -7760,7 +7760,7 @@ static void hpsa_free_pci_init(struct ctlr_info *h)
> hpsa_disable_interrupt_mode(h); /* pci_init 2 */
> /*
> * call pci_disable_device before pci_release_regions per
> - * Documentation/PCI/pci.txt
> + * Documentation/PCI/pci.rst
> */
> pci_disable_device(h->pdev); /* pci_init 1 */
> pci_release_regions(h->pdev); /* pci_init 2 */
> @@ -7843,7 +7843,7 @@ static int hpsa_pci_init(struct ctlr_info *h)
> clean1:
> /*
> * call pci_disable_device before pci_release_regions per
> - * Documentation/PCI/pci.txt
> + * Documentation/PCI/pci.rst
> */
> pci_disable_device(h->pdev);
> pci_release_regions(h->pdev);
> --
> 2.21.0
>
^ permalink raw reply
* Re: [PATCH v3 17/20] dt: bindings: fix some broken links from txt->yaml conversion
From: Mauro Carvalho Chehab @ 2019-06-08 10:51 UTC (permalink / raw)
To: Mark Brown
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Hugues Fruchet, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Olivier Moysan,
Arnaud Pouliquen, Liam Girdwood, devicetree, linux-stm32,
linux-arm-kernel, alsa-devel
In-Reply-To: <20190607185728.GJ2456@sirena.org.uk>
Em Fri, 7 Jun 2019 19:57:28 +0100
Mark Brown <broonie@kernel.org> escreveu:
> On Fri, Jun 07, 2019 at 03:54:33PM -0300, Mauro Carvalho Chehab wrote:
> > Some new files got converted to yaml, but references weren't
> > updated accordingly.
>
> These should probably just be sent as normal patches rather than tied in
> with the rest of this series...
Thanks for applying it!
Yeah, but the problem with documentation patches is that sometimes
the patches are merged via docs tree, and sometimes via maintainer's
tree, depending on the subsystem.
Anyway, Jon merged this week a patch that should produce warnings
on COMPILE_TEST builds when a file has a broken link.
Hopefully, this will help a lot to warn people against regressions
related to it.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH v2 12/22] docs: gpio: driver.rst: fix a bad tag
From: Mauro Carvalho Chehab @ 2019-06-08 9:42 UTC (permalink / raw)
To: Linus Walleij
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab,
linux-kernel@vger.kernel.org, Jonathan Corbet,
Bartosz Golaszewski, open list:GPIO SUBSYSTEM
In-Reply-To: <CACRpkdayQdrtqO3aygY1uDG0LCX_9rVnSnxP5F_C-KMZURTAYA@mail.gmail.com>
Hi Linus,
Em Sat, 8 Jun 2019 00:08:10 +0200
Linus Walleij <linus.walleij@linaro.org> escreveu:
> On Tue, Jun 4, 2019 at 4:18 PM Mauro Carvalho Chehab
> <mchehab+samsung@kernel.org> wrote:
>
> > With ReST, [foo]_ means a reference to foo, causing this warning:
> >
> > Documentation/driver-api/gpio/driver.rst:419: WARNING: Unknown target name: "devm".
> >
> > Fix it by using a literal for the name.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
>
> Looks identical to the v1 I already applied, so keeping
> that one.
Thanks for applying it.
Yeah, it should be identical (and so it should be the v3 I sent yesterday).
v2 and v3 are just rebases on the top of linux-next.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH] Documentation: fix typo CLOCK_MONONOTNIC_COARSE
From: Aurelien Thierry @ 2019-06-08 9:37 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Arnd Bergmann, John Stultz, Thomas Gleixner, Linus Walleij,
Randy Dunlap, linux-doc, trivial
In-Reply-To: <20190607112233.1b91c3bb@lwn.net>
It is indeed my first kernel patch, I'll definitely make sure that I
can apply the patch next time.
Thank you!
Aurelien
On 6/7/19 7:22 PM, Jonathan Corbet wrote:
> On Fri, 7 Jun 2019 10:07:02 +0200
> Aurelien Thierry <aurelien.thierry@quoscient.io> wrote:
>
>> Fix typo in documentation file timekeeping.rst: CLOCK_MONONOTNIC_COARSE
>> should be CLOCK_MONOTONIC_COARSE.
>>
>> Signed-off-by: Aurelien Thierry <aurelien.thierry@quoscient.io>
>> ---
>> Documentation/core-api/timekeeping.rst | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/core-api/timekeeping.rst
>> b/Documentation/core-api/timekeeping.rst
>> index 93cbeb9daec0..5f87d9c8b04d 100644
>> --- a/Documentation/core-api/timekeeping.rst
>> +++ b/Documentation/core-api/timekeeping.rst
>> @@ -111,7 +111,7 @@ Some additional variants exist for more specialized
>> cases:
>> void ktime_get_coarse_raw_ts64( struct timespec64 * )
>>
>> These are quicker than the non-coarse versions, but less accurate,
>> - corresponding to CLOCK_MONONOTNIC_COARSE and CLOCK_REALTIME_COARSE
>> + corresponding to CLOCK_MONOTONIC_COARSE and CLOCK_REALTIME_COARSE
>> in user space, along with the equivalent boottime/tai/raw
>> timebase not available in user space.
>
> Patch applied; congratulations on what appears to be your first kernel
> patch!
>
> Note that this patch was badly corrupted by your mailer; it took me a
> while to unmangle it. Before sending your next one, I'd recommend being
> sure that you can email it to yourself and apply the result. There are
> some hints in Documentation/process/email-clients.rst.
>
> Thanks,
>
> jon
>
^ permalink raw reply
* Re: [PATCH v12 05/13] clk: ingenic: Add driver for the TCU clocks
From: Stephen Boyd @ 2019-06-07 22:50 UTC (permalink / raw)
To: Paul Cercueil
Cc: Daniel Lezcano, James Hogan, Jason Cooper, Jonathan Corbet,
Lee Jones, Marc Zyngier, Mark Rutland, Michael Turquette,
Paul Burton, Ralf Baechle, Rob Herring, Thomas Gleixner,
Mathieu Malaterre, linux-kernel, devicetree, linux-mips,
linux-doc, linux-clk, od
In-Reply-To: <1559944794.11351.0@crapouillou.net>
Quoting Paul Cercueil (2019-06-07 14:59:54)
> Hi Stephen, thanks for the review.
> > Quoting Paul Cercueil (2019-05-21 07:51:33)
> >> diff --git a/drivers/clk/ingenic/tcu.c b/drivers/clk/ingenic/tcu.c
> >> new file mode 100644
> >> index 000000000000..7249225a6994
> >> --- /dev/null
> >> +++ b/drivers/clk/ingenic/tcu.c
> >> @@ -0,0 +1,458 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/*
> >> + * JZ47xx SoCs TCU clocks driver
> >> + * Copyright (C) 2019 Paul Cercueil <paul@crapouillou.net>
> >> + */
> >> +
> >> +#include <linux/clk.h>
> >> +#include <linux/clk-provider.h>
> >> +#include <linux/clkdev.h>
> >> +#include <linux/clockchips.h>
> >> +#include <linux/mfd/ingenic-tcu.h>
> >> +#include <linux/regmap.h>
> >> +
> >> +#include <dt-bindings/clock/ingenic,tcu.h>
> >> +
> >> +/* 8 channels max + watchdog + OST */
> >> +#define TCU_CLK_COUNT 10
> >> +
> >> +#define TCU_ERR(...) pr_crit("ingenic-tcu-clk: " __VA_ARGS__)
> >
> > Why is it pr_crit instead of pr_err()?
>
> If the TCU timer clocks are not provided for any reason, the system
> will have no timer, and the kernel will hang very early in the init
> process. That's why I chose pr_crit().
HMm. So maybe it should be TCU_CRIT() then? Or just drop the wrapper
macro and define a pr_fmt for this file that has ingenic-tcu-clk: for
it?
>
> Most of the code here works without a struct device, it wouldn't be
> easy to
> get it to work with runtime PM.
>
> I can enable the "tcu" clock in the probe and just gate/ungate it in the
> suspend/resume callbacks, that would work just fine. We don't need
> anything
> fancy here.
OK. That sounds like a better approach to gate and ungate in
suspend/resume.
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Andy Lutomirski @ 2019-06-07 22:27 UTC (permalink / raw)
To: Dave Hansen
Cc: Yu-cheng Yu, Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner,
Ingo Molnar, linux-kernel, linux-doc, linux-mm, linux-arch,
linux-api, Arnd Bergmann, Balbir Singh, Borislav Petkov,
Cyrill Gorcunov, Dave Hansen, Eugene Syromiatnikov,
Florian Weimer, H.J. Lu, Jann Horn, Jonathan Corbet, Kees Cook,
Mike Kravetz, Nadav Amit, Oleg Nesterov, Pavel Machek,
Randy Dunlap, Ravi V. Shankar, Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <f6de9073-9939-a20d-2196-25fa223cf3fc@intel.com>
> On Jun 7, 2019, at 2:09 PM, Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 6/7/19 1:06 PM, Yu-cheng Yu wrote:
>>> Huh, how does glibc know about all possible past and future legacy code
>>> in the application?
>> When dlopen() gets a legacy binary and the policy allows that, it will manage
>> the bitmap:
>>
>> If a bitmap has not been created, create one.
>> Set bits for the legacy code being loaded.
>
> I was thinking about code that doesn't go through GLIBC like JITs.
CRIU is another consideration: it would be rather annoying if CET programs can’t migrate between LA57 and normal machines.
^ permalink raw reply
* Re: [PATCH v4 17/18] kernel/sysctl-test: Add null pointer test for sysctl.c:proc_dointvec()
From: Brendan Higgins @ 2019-06-07 22:22 UTC (permalink / raw)
To: Stephen Boyd
Cc: Iurii Zaikin, Frank Rowand, Greg KH, Josh Poimboeuf, Kees Cook,
Kieran Bingham, Luis Chamberlain, Peter Zijlstra, Rob Herring,
shuah, Theodore Ts'o, Masahiro Yamada, devicetree, dri-devel,
kunit-dev, open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK,
linux-nvdimm, linux-um, Sasha Levin, Bird, Timothy,
Amir Goldstein, Dan Carpenter, Daniel Vetter, Jeff Dike,
Joel Stanley, Julia Lawall, Kevin Hilman, Knut Omang,
Logan Gunthorpe, Michael Ellerman, Petr Mladek, Randy Dunlap,
Richard Weinberger, David Rientjes, Steven Rostedt, wfg
In-Reply-To: <20190607190047.C3E7A20868@mail.kernel.org>
On Fri, Jun 7, 2019 at 12:00 PM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Iurii Zaikin (2019-06-05 18:29:42)
> > On Fri, May 17, 2019 at 11:22 AM Stephen Boyd <sboyd@kernel.org> wrote:
> > >
> > > Quoting Brendan Higgins (2019-05-14 15:17:10)
> > > > diff --git a/kernel/sysctl-test.c b/kernel/sysctl-test.c
> > > > new file mode 100644
> > > > index 0000000000000..fe0f2bae66085
> > > > --- /dev/null
> > > > +++ b/kernel/sysctl-test.c
> > > > +
> > > > +
> > > > +static void sysctl_test_dointvec_happy_single_negative(struct kunit *test)
> > > > +{
> > > > + struct ctl_table table = {
> > > > + .procname = "foo",
> > > > + .data = &test_data.int_0001,
> > > > + .maxlen = sizeof(int),
> > > > + .mode = 0644,
> > > > + .proc_handler = proc_dointvec,
> > > > + .extra1 = &i_zero,
> > > > + .extra2 = &i_one_hundred,
> > > > + };
> > > > + char input[] = "-9";
> > > > + size_t len = sizeof(input) - 1;
> > > > + loff_t pos = 0;
> > > > +
> > > > + table.data = kunit_kzalloc(test, sizeof(int), GFP_USER);
> > > > + KUNIT_EXPECT_EQ(test, 0, proc_dointvec(&table, 1, input, &len, &pos));
> > > > + KUNIT_EXPECT_EQ(test, sizeof(input) - 1, len);
> > > > + KUNIT_EXPECT_EQ(test, sizeof(input) - 1, pos);
> > > > + KUNIT_EXPECT_EQ(test, -9, *(int *)table.data);
> > >
> > > Is the casting necessary? Or can the macro do a type coercion of the
> > > second parameter based on the first type?
> > Data field is defined as void* so I believe casting is necessary to
> > dereference it as a pointer to an array of ints. I don't think the
> > macro should do any type coercion that == operator wouldn't do.
> > I did change the cast to make it more clear that it's a pointer to an
> > array of ints being dereferenced.
>
> Ok, I still wonder if we should make KUNIT_EXPECT_EQ check the types on
> both sides and cause a build warning/error if the types aren't the same.
> This would be similar to our min/max macros that complain about
> mismatched types in the comparisons. Then if a test developer needs to
> convert one type or the other they could do so with a
> KUNIT_EXPECT_EQ_T() macro that lists the types to coerce both sides to
> explicitly.
Good point. I would definitely like to do this, for me it is only a
question of how difficult it would be to make all that happen.
We will investigate and report back on it.
Thanks for the suggestion! It's a really good idea!
Cheers
^ permalink raw reply
* Re: [PATCH v2 12/22] docs: gpio: driver.rst: fix a bad tag
From: Linus Walleij @ 2019-06-07 22:08 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab,
linux-kernel@vger.kernel.org, Jonathan Corbet,
Bartosz Golaszewski, open list:GPIO SUBSYSTEM
In-Reply-To: <ee8f4f56658247a0ab0d9e2c16a9afafefe38da0.1559656538.git.mchehab+samsung@kernel.org>
On Tue, Jun 4, 2019 at 4:18 PM Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
> With ReST, [foo]_ means a reference to foo, causing this warning:
>
> Documentation/driver-api/gpio/driver.rst:419: WARNING: Unknown target name: "devm".
>
> Fix it by using a literal for the name.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Looks identical to the v1 I already applied, so keeping
that one.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v12 05/13] clk: ingenic: Add driver for the TCU clocks
From: Paul Cercueil @ 2019-06-07 21:59 UTC (permalink / raw)
To: Stephen Boyd
Cc: Daniel Lezcano, James Hogan, Jason Cooper, Jonathan Corbet,
Lee Jones, Marc Zyngier, Mark Rutland, Michael Turquette,
Paul Burton, Ralf Baechle, Rob Herring, Thomas Gleixner,
Mathieu Malaterre, linux-kernel, devicetree, linux-mips,
linux-doc, linux-clk, od
In-Reply-To: <20190607212819.A5FAE208C3@mail.kernel.org>
Hi Stephen, thanks for the review.
Le ven. 7 juin 2019 à 23:28, Stephen Boyd <sboyd@kernel.org> a écrit :
> Quoting Paul Cercueil (2019-05-21 07:51:33)
>> diff --git a/drivers/clk/ingenic/Kconfig
>> b/drivers/clk/ingenic/Kconfig
>> index 34dc0da79c39..434893133eb4 100644
>> --- a/drivers/clk/ingenic/Kconfig
>> +++ b/drivers/clk/ingenic/Kconfig
>> @@ -1,4 +1,4 @@
>> -menu "Ingenic JZ47xx CGU drivers"
>> +menu "Ingenic JZ47xx drivers"
>> depends on MIPS
>>
>> config INGENIC_CGU_COMMON
>> @@ -44,4 +44,13 @@ config INGENIC_CGU_JZ4780
>>
>> If building for a JZ4780 SoC, you want to say Y here.
>>
>> +config INGENIC_TCU_CLK
>> + bool "Ingenic JZ47xx TCU clocks driver"
>> + default MACH_INGENIC
>> + depends on COMMON_CLK
>
> Does the INGENIC_TCU_CLK config even exist if COMMON_CLK is disabled?
> I
> suspect it's all part of the menuconfig so this depends is not useful?
Right, it can be dropped.
>> + select INGENIC_TCU
>> + help
>> + Support the clocks of the Timer/Counter Unit (TCU) of the
>> Ingenic
>> + JZ47xx SoCs.
>> +
>> endmenu
>> diff --git a/drivers/clk/ingenic/tcu.c b/drivers/clk/ingenic/tcu.c
>> new file mode 100644
>> index 000000000000..7249225a6994
>> --- /dev/null
>> +++ b/drivers/clk/ingenic/tcu.c
>> @@ -0,0 +1,458 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * JZ47xx SoCs TCU clocks driver
>> + * Copyright (C) 2019 Paul Cercueil <paul@crapouillou.net>
>> + */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/clk-provider.h>
>> +#include <linux/clkdev.h>
>> +#include <linux/clockchips.h>
>> +#include <linux/mfd/ingenic-tcu.h>
>> +#include <linux/regmap.h>
>> +
>> +#include <dt-bindings/clock/ingenic,tcu.h>
>> +
>> +/* 8 channels max + watchdog + OST */
>> +#define TCU_CLK_COUNT 10
>> +
>> +#define TCU_ERR(...) pr_crit("ingenic-tcu-clk: " __VA_ARGS__)
>
> Why is it pr_crit instead of pr_err()?
If the TCU timer clocks are not provided for any reason, the system
will have no timer, and the kernel will hang very early in the init
process. That's why I chose pr_crit().
>> +
>> +enum tcu_clk_parent {
>> + TCU_PARENT_PCLK,
>> + TCU_PARENT_RTC,
>> + TCU_PARENT_EXT,
>> +};
>> +
> [...]
>> +
>> +static int __init ingenic_tcu_register_clock(struct ingenic_tcu
>> *tcu,
>> + unsigned int idx, enum tcu_clk_parent
>> parent,
>> + const struct ingenic_tcu_clk_info *info,
>> + struct clk_hw_onecell_data *clocks)
>> +{
>> + struct ingenic_tcu_clk *tcu_clk;
>> + int err;
>> +
>> + tcu_clk = kzalloc(sizeof(*tcu_clk), GFP_KERNEL);
>> + if (!tcu_clk)
>> + return -ENOMEM;
>> +
>> + tcu_clk->hw.init = &info->init_data;
>> + tcu_clk->idx = idx;
>> + tcu_clk->info = info;
>> + tcu_clk->tcu = tcu;
>> +
>> + /* Reset channel and clock divider, set default parent */
>> + ingenic_tcu_enable_regs(&tcu_clk->hw);
>> + regmap_update_bits(tcu->map, info->tcsr_reg, 0xffff,
>> BIT(parent));
>> + ingenic_tcu_disable_regs(&tcu_clk->hw);
>> +
>> + err = clk_hw_register(NULL, &tcu_clk->hw);
>> + if (err)
>> + goto err_free_tcu_clk;
>> +
>> + err = clk_hw_register_clkdev(&tcu_clk->hw,
>> info->init_data.name, NULL);
>
> Do you have a use for clkdev? If DT lookups work just as well it would
> be better to skip clkdev registration.
OK.
>> + if (err)
>> + goto err_clk_unregister;
>> +
>> + clocks->hws[idx] = &tcu_clk->hw;
>> +
>> + return 0;
>> +
>> +err_clk_unregister:
>> + clk_hw_unregister(&tcu_clk->hw);
>> +err_free_tcu_clk:
>> + kfree(tcu_clk);
>> + return err;
>> +}
>> +
>> +static const struct ingenic_soc_info jz4740_soc_info = {
>> + .num_channels = 8,
>> + .has_ost = false,
>> + .has_tcu_clk = true,
>> +};
>> +
>> +static const struct ingenic_soc_info jz4725b_soc_info = {
>> + .num_channels = 6,
>> + .has_ost = true,
>> + .has_tcu_clk = true,
>> +};
>> +
>> +static const struct ingenic_soc_info jz4770_soc_info = {
>> + .num_channels = 8,
>> + .has_ost = true,
>> + .has_tcu_clk = false,
>> +};
>> +
>> +static const struct of_device_id ingenic_tcu_of_match[]
>> __initconst = {
>> + { .compatible = "ingenic,jz4740-tcu", .data =
>> &jz4740_soc_info, },
>> + { .compatible = "ingenic,jz4725b-tcu", .data =
>> &jz4725b_soc_info, },
>> + { .compatible = "ingenic,jz4770-tcu", .data =
>> &jz4770_soc_info, },
>> + { }
>> +};
>> +
>> +static int __init ingenic_tcu_probe(struct device_node *np)
>> +{
>> + const struct of_device_id *id =
>> of_match_node(ingenic_tcu_of_match, np);
>> + struct ingenic_tcu *tcu;
>> + struct regmap *map;
>> + unsigned int i;
>> + int ret;
>> +
>> + map = ingenic_tcu_get_regmap(np);
>> + if (IS_ERR(map))
>> + return PTR_ERR(map);
>> +
>> + tcu = kzalloc(sizeof(*tcu), GFP_KERNEL);
>> + if (!tcu)
>> + return -ENOMEM;
>> +
>> + tcu->map = map;
>> + tcu->soc_info = id->data;
>> +
>> + if (tcu->soc_info->has_tcu_clk) {
>> + tcu->clk = of_clk_get_by_name(np, "tcu");
>
> Is this clk necessary to read/write registers in this clk driver? And
> this clk isn't the parent of the clks? Why is it managed by Linux at
> all? Will there be a time when it's turned off?
For the SoCs which have the "tcu" clock, it has to be enabled for the
registers to be accessible, yes. And as you noticed, it is not the
parent of the timer clocks.
The "tcu" clock can be turned off during suspend, for instance.
> I'm asking because it looks like we're calling clk APIs from within
> clk
> provider implementation. That works right now because of our locking
> scheme, but this will put up another roadblock to making the prepare
> and
> enable locks not recursive. I've seen some drivers take an approach of
> enabling the clk when the provider is PM runtime active, and disable
> the
> clk when the provider is runtime PM inactive. This gets it out of the
> provider path and into the runtime PM path. If you take that approach
> then when we move the runtime PM code in clk core outside of the
> prepare
> lock we should be able to avoid any recursive locking scenarios.
Most of the code here works without a struct device, it wouldn't be
easy to
get it to work with runtime PM.
I can enable the "tcu" clock in the probe and just gate/ungate it in the
suspend/resume callbacks, that would work just fine. We don't need
anything
fancy here.
>> + if (IS_ERR(tcu->clk)) {
>> + ret = PTR_ERR(tcu->clk);
>> + TCU_ERR("Cannot get TCU clock\n");
>> + goto err_free_tcu;
>> + }
>> +
^ permalink raw reply
* Re: [PATCH 4/4] Documentation: x86: fix some typos
From: Fenghua Yu @ 2019-06-07 21:29 UTC (permalink / raw)
To: James Morse
Cc: linux-doc, x86, Jonathan Corbet, Reinette Chatre, Babu Moger,
linux-kernel
In-Reply-To: <20190607151409.15476-5-james.morse@arm.com>
On Fri, Jun 07, 2019 at 04:14:09PM +0100, James Morse wrote:
> These are all obvious typos.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
> Documentation/x86/resctrl_ui.rst | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/x86/resctrl_ui.rst b/Documentation/x86/resctrl_ui.rst
> index 866b66aa289b..5368cedfb530 100644
> --- a/Documentation/x86/resctrl_ui.rst
> +++ b/Documentation/x86/resctrl_ui.rst
> @@ -40,7 +40,7 @@ mount options are:
> Enable the MBA Software Controller(mba_sc) to specify MBA
> bandwidth in MBps
>
> -L2 and L3 CDP are controlled seperately.
> +L2 and L3 CDP are controlled separately.
>
> RDT features are orthogonal. A particular system may support only
> monitoring, only control, or both monitoring and control. Cache
> @@ -118,7 +118,7 @@ related to allocation:
> Corresponding region is pseudo-locked. No
> sharing allowed.
>
> -Memory bandwitdh(MB) subdirectory contains the following files
> +Memory bandwidth(MB) subdirectory contains the following files
> with respect to allocation:
>
> "min_bandwidth":
> @@ -209,7 +209,7 @@ All groups contain the following files:
> CPUs to/from this group. As with the tasks file a hierarchy is
> maintained where MON groups may only include CPUs owned by the
> parent CTRL_MON group.
> - When the resouce group is in pseudo-locked mode this file will
> + When the resource group is in pseudo-locked mode this file will
> only be readable, reflecting the CPUs associated with the
> pseudo-locked region.
>
> @@ -380,7 +380,7 @@ where L2 external is 10GBps (hence aggregate L2 external bandwidth is
> 240GBps) and L3 external bandwidth is 100GBps. Now a workload with '20
> threads, having 50% bandwidth, each consuming 5GBps' consumes the max L3
> bandwidth of 100GBps although the percentage value specified is only 50%
> -<< 100%. Hence increasing the bandwidth percentage will not yeild any
> +<< 100%. Hence increasing the bandwidth percentage will not yield any
> more bandwidth. This is because although the L2 external bandwidth still
> has capacity, the L3 external bandwidth is fully used. Also note that
> this would be dependent on number of cores the benchmark is run on.
> @@ -398,7 +398,7 @@ In order to mitigate this and make the interface more user friendly,
> resctrl added support for specifying the bandwidth in MBps as well. The
> kernel underneath would use a software feedback mechanism or a "Software
> Controller(mba_sc)" which reads the actual bandwidth using MBM counters
> -and adjust the memowy bandwidth percentages to ensure::
> +and adjust the memory bandwidth percentages to ensure::
>
> "actual bandwidth < user specified bandwidth".
>
> --
> 2.20.1
>
Acked-by: Fenghua Yu <fenghua.yu@intel.com>
Thanks.
-Fenghua
^ permalink raw reply
* Re: [PATCH 3/4] Documentation: x86: Clarify MBA takes MB as referring to mba_sc
From: Fenghua Yu @ 2019-06-07 21:28 UTC (permalink / raw)
To: James Morse
Cc: linux-doc, x86, Jonathan Corbet, Reinette Chatre, Babu Moger,
linux-kernel
In-Reply-To: <20190607151409.15476-4-james.morse@arm.com>
On Fri, Jun 07, 2019 at 04:14:08PM +0100, James Morse wrote:
> "If the MBA is specified in MB then user can enter the max b/w in MB"
> is a tautology. How can the user know if the schemata takes a percentage
> or a MB/s value?
>
> This is referring to whether the software controller is interpreting
> the schemata's value. Make this clear.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
> Documentation/x86/resctrl_ui.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/x86/resctrl_ui.rst b/Documentation/x86/resctrl_ui.rst
> index 638cd987937d..866b66aa289b 100644
> --- a/Documentation/x86/resctrl_ui.rst
> +++ b/Documentation/x86/resctrl_ui.rst
> @@ -677,8 +677,8 @@ allocations can overlap or not. The allocations specifies the maximum
> b/w that the group may be able to use and the system admin can configure
> the b/w accordingly.
>
> -If the MBA is specified in MB(megabytes) then user can enter the max b/w in MB
> -rather than the percentage values.
> +If resctrl is using the software controller (mba_sc) then user can enter the
> +max b/w in MB rather than the percentage values.
> ::
>
> # echo "L3:0=3;1=c\nMB:0=1024;1=500" > /sys/fs/resctrl/p0/schemata
> --
> 2.20.1
>
Acked-by: Fenghua Yu <fenghua.yu@intel.com>
Thanks.
-Fenghua
^ permalink raw reply
* Re: [PATCH 2/4] Documentation: x86: Remove cdpl2 unspported statement and fix capitalisation
From: Fenghua Yu @ 2019-06-07 21:26 UTC (permalink / raw)
To: James Morse
Cc: linux-doc, x86, Jonathan Corbet, Reinette Chatre, Babu Moger,
linux-kernel
In-Reply-To: <20190607151409.15476-3-james.morse@arm.com>
On Fri, Jun 07, 2019 at 04:14:07PM +0100, James Morse wrote:
> "L2 cache does not support code and data prioritization". This isn't
> true, elsewhere the document says it can be enabled with the cdpl2
> mount option.
>
> While we're here, these sample strings have lower-case code/data,
> which isn't how the kernel exports them.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
> Documentation/x86/resctrl_ui.rst | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/x86/resctrl_ui.rst b/Documentation/x86/resctrl_ui.rst
> index 066f94e53418..638cd987937d 100644
> --- a/Documentation/x86/resctrl_ui.rst
> +++ b/Documentation/x86/resctrl_ui.rst
> @@ -418,16 +418,22 @@ L3 schemata file details (CDP enabled via mount option to resctrl)
> When CDP is enabled L3 control is split into two separate resources
> so you can specify independent masks for code and data like this::
>
> - L3data:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
> - L3code:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
> + L3DATA:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
> + L3CODE:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
>
> L2 schemata file details
> ------------------------
> -L2 cache does not support code and data prioritization, so the
> -schemata format is always::
> +CDP is supported at L2 using the 'cdpl2' mount option. The schemata
> +format is either::
>
> L2:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
>
> +or
> +
> + L2DATA:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
> + L2CODE:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
> +
> +
> Memory bandwidth Allocation (default mode)
> ------------------------------------------
>
> --
> 2.20.1
>
Acked-by: Fenghua Yu <fenghua.yu@intel.com>
Thanks.
-Fenghua
^ permalink raw reply
* Re: [PATCH 1/4] Documentation: x86: Contiguous cbm isn't all X86
From: Fenghua Yu @ 2019-06-07 21:24 UTC (permalink / raw)
To: James Morse
Cc: linux-doc, x86, Jonathan Corbet, Reinette Chatre, Babu Moger,
linux-kernel
In-Reply-To: <20190607151409.15476-2-james.morse@arm.com>
On Fri, Jun 07, 2019 at 04:14:06PM +0100, James Morse wrote:
> Since commit 4d05bf71f157 ("x86/resctrl: Introduce AMD QOS feature")
> resctrl has supported non-contiguous cache bit masks. The interface
> for this is currently try-it-and-see.
>
> Update the documentation to say Intel CPUs have this requirement,
> instead of X86.
>
> Cc: Babu Moger <Babu.Moger@amd.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
> Documentation/x86/resctrl_ui.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/x86/resctrl_ui.rst b/Documentation/x86/resctrl_ui.rst
> index 225cfd4daaee..066f94e53418 100644
> --- a/Documentation/x86/resctrl_ui.rst
> +++ b/Documentation/x86/resctrl_ui.rst
> @@ -342,7 +342,7 @@ For cache resources we describe the portion of the cache that is available
> for allocation using a bitmask. The maximum value of the mask is defined
> by each cpu model (and may be different for different cache levels). It
> is found using CPUID, but is also provided in the "info" directory of
> -the resctrl file system in "info/{resource}/cbm_mask". X86 hardware
> +the resctrl file system in "info/{resource}/cbm_mask". Intel hardware
> requires that these masks have all the '1' bits in a contiguous block. So
> 0x3, 0x6 and 0xC are legal 4-bit masks with two bits set, but 0x5, 0x9
> and 0xA are not. On a system with a 20-bit mask each bit represents 5%
> --
> 2.20.1
>
Acked-by: Fenghua Yu <fenghua.yu@intel.com>
Thanks.
-Fenghua Yu
^ permalink raw reply
* Re: [PATCH v12 05/13] clk: ingenic: Add driver for the TCU clocks
From: Stephen Boyd @ 2019-06-07 21:28 UTC (permalink / raw)
To: 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: Mathieu Malaterre, linux-kernel, devicetree, linux-mips,
linux-doc, linux-clk, od, Paul Cercueil
In-Reply-To: <20190521145141.9813-6-paul@crapouillou.net>
Quoting Paul Cercueil (2019-05-21 07:51:33)
> diff --git a/drivers/clk/ingenic/Kconfig b/drivers/clk/ingenic/Kconfig
> index 34dc0da79c39..434893133eb4 100644
> --- a/drivers/clk/ingenic/Kconfig
> +++ b/drivers/clk/ingenic/Kconfig
> @@ -1,4 +1,4 @@
> -menu "Ingenic JZ47xx CGU drivers"
> +menu "Ingenic JZ47xx drivers"
> depends on MIPS
>
> config INGENIC_CGU_COMMON
> @@ -44,4 +44,13 @@ config INGENIC_CGU_JZ4780
>
> If building for a JZ4780 SoC, you want to say Y here.
>
> +config INGENIC_TCU_CLK
> + bool "Ingenic JZ47xx TCU clocks driver"
> + default MACH_INGENIC
> + depends on COMMON_CLK
Does the INGENIC_TCU_CLK config even exist if COMMON_CLK is disabled? I
suspect it's all part of the menuconfig so this depends is not useful?
> + select INGENIC_TCU
> + help
> + Support the clocks of the Timer/Counter Unit (TCU) of the Ingenic
> + JZ47xx SoCs.
> +
> endmenu
> diff --git a/drivers/clk/ingenic/tcu.c b/drivers/clk/ingenic/tcu.c
> new file mode 100644
> index 000000000000..7249225a6994
> --- /dev/null
> +++ b/drivers/clk/ingenic/tcu.c
> @@ -0,0 +1,458 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * JZ47xx SoCs TCU clocks driver
> + * Copyright (C) 2019 Paul Cercueil <paul@crapouillou.net>
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clk-provider.h>
> +#include <linux/clkdev.h>
> +#include <linux/clockchips.h>
> +#include <linux/mfd/ingenic-tcu.h>
> +#include <linux/regmap.h>
> +
> +#include <dt-bindings/clock/ingenic,tcu.h>
> +
> +/* 8 channels max + watchdog + OST */
> +#define TCU_CLK_COUNT 10
> +
> +#define TCU_ERR(...) pr_crit("ingenic-tcu-clk: " __VA_ARGS__)
Why is it pr_crit instead of pr_err()?
> +
> +enum tcu_clk_parent {
> + TCU_PARENT_PCLK,
> + TCU_PARENT_RTC,
> + TCU_PARENT_EXT,
> +};
> +
[...]
> +
> +static int __init ingenic_tcu_register_clock(struct ingenic_tcu *tcu,
> + unsigned int idx, enum tcu_clk_parent parent,
> + const struct ingenic_tcu_clk_info *info,
> + struct clk_hw_onecell_data *clocks)
> +{
> + struct ingenic_tcu_clk *tcu_clk;
> + int err;
> +
> + tcu_clk = kzalloc(sizeof(*tcu_clk), GFP_KERNEL);
> + if (!tcu_clk)
> + return -ENOMEM;
> +
> + tcu_clk->hw.init = &info->init_data;
> + tcu_clk->idx = idx;
> + tcu_clk->info = info;
> + tcu_clk->tcu = tcu;
> +
> + /* Reset channel and clock divider, set default parent */
> + ingenic_tcu_enable_regs(&tcu_clk->hw);
> + regmap_update_bits(tcu->map, info->tcsr_reg, 0xffff, BIT(parent));
> + ingenic_tcu_disable_regs(&tcu_clk->hw);
> +
> + err = clk_hw_register(NULL, &tcu_clk->hw);
> + if (err)
> + goto err_free_tcu_clk;
> +
> + err = clk_hw_register_clkdev(&tcu_clk->hw, info->init_data.name, NULL);
Do you have a use for clkdev? If DT lookups work just as well it would
be better to skip clkdev registration.
> + if (err)
> + goto err_clk_unregister;
> +
> + clocks->hws[idx] = &tcu_clk->hw;
> +
> + return 0;
> +
> +err_clk_unregister:
> + clk_hw_unregister(&tcu_clk->hw);
> +err_free_tcu_clk:
> + kfree(tcu_clk);
> + return err;
> +}
> +
> +static const struct ingenic_soc_info jz4740_soc_info = {
> + .num_channels = 8,
> + .has_ost = false,
> + .has_tcu_clk = true,
> +};
> +
> +static const struct ingenic_soc_info jz4725b_soc_info = {
> + .num_channels = 6,
> + .has_ost = true,
> + .has_tcu_clk = true,
> +};
> +
> +static const struct ingenic_soc_info jz4770_soc_info = {
> + .num_channels = 8,
> + .has_ost = true,
> + .has_tcu_clk = false,
> +};
> +
> +static const struct of_device_id ingenic_tcu_of_match[] __initconst = {
> + { .compatible = "ingenic,jz4740-tcu", .data = &jz4740_soc_info, },
> + { .compatible = "ingenic,jz4725b-tcu", .data = &jz4725b_soc_info, },
> + { .compatible = "ingenic,jz4770-tcu", .data = &jz4770_soc_info, },
> + { }
> +};
> +
> +static int __init ingenic_tcu_probe(struct device_node *np)
> +{
> + const struct of_device_id *id = of_match_node(ingenic_tcu_of_match, np);
> + struct ingenic_tcu *tcu;
> + struct regmap *map;
> + unsigned int i;
> + int ret;
> +
> + map = ingenic_tcu_get_regmap(np);
> + if (IS_ERR(map))
> + return PTR_ERR(map);
> +
> + tcu = kzalloc(sizeof(*tcu), GFP_KERNEL);
> + if (!tcu)
> + return -ENOMEM;
> +
> + tcu->map = map;
> + tcu->soc_info = id->data;
> +
> + if (tcu->soc_info->has_tcu_clk) {
> + tcu->clk = of_clk_get_by_name(np, "tcu");
Is this clk necessary to read/write registers in this clk driver? And
this clk isn't the parent of the clks? Why is it managed by Linux at
all? Will there be a time when it's turned off?
I'm asking because it looks like we're calling clk APIs from within clk
provider implementation. That works right now because of our locking
scheme, but this will put up another roadblock to making the prepare and
enable locks not recursive. I've seen some drivers take an approach of
enabling the clk when the provider is PM runtime active, and disable the
clk when the provider is runtime PM inactive. This gets it out of the
provider path and into the runtime PM path. If you take that approach
then when we move the runtime PM code in clk core outside of the prepare
lock we should be able to avoid any recursive locking scenarios.
> + if (IS_ERR(tcu->clk)) {
> + ret = PTR_ERR(tcu->clk);
> + TCU_ERR("Cannot get TCU clock\n");
> + goto err_free_tcu;
> + }
> +
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Dave Hansen @ 2019-06-07 21:09 UTC (permalink / raw)
To: Yu-cheng Yu, Andy Lutomirski
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <0e505563f7dae3849b57fb327f578f41b760b6f7.camel@intel.com>
On 6/7/19 1:06 PM, Yu-cheng Yu wrote:
>> Huh, how does glibc know about all possible past and future legacy code
>> in the application?
> When dlopen() gets a legacy binary and the policy allows that, it will manage
> the bitmap:
>
> If a bitmap has not been created, create one.
> Set bits for the legacy code being loaded.
I was thinking about code that doesn't go through GLIBC like JITs.
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Dave Hansen @ 2019-06-07 21:05 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Peter Zijlstra, Yu-cheng Yu, x86, H. Peter Anvin, Thomas Gleixner,
Ingo Molnar, linux-kernel, linux-doc, linux-mm, linux-arch,
linux-api, Arnd Bergmann, Balbir Singh, Borislav Petkov,
Cyrill Gorcunov, Dave Hansen, Eugene Syromiatnikov,
Florian Weimer, H.J. Lu, Jann Horn, Jonathan Corbet, Kees Cook,
Mike Kravetz, Nadav Amit, Oleg Nesterov, Pavel Machek,
Randy Dunlap, Ravi V. Shankar, Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <D10B5B59-1BE7-44DC-8E91-C8E4292DC6FB@amacapital.net>
On 6/7/19 1:40 PM, Andy Lutomirski wrote:
>>> Hmm. Can we be creative and skip populating it with zeros? The
>>> CPU
>> should only ever touch a page if we miss an ENDBR on it, so, in
>> normal operation, we don’t need anything to be there. We could try
>> to prevent anyone from *reading* it outside of ENDBR tracking if we
>> want to avoid people accidentally wasting lots of memory by forcing
>> it to be fully populated when the read it.
>>
>> Won't reads on a big, contiguous private mapping get the huge zero
>> page anyway?
>
> The zero pages may be free, but the page tables could be decently
large. Does the core mm code use huge, immense, etc huge zero pages?
Or can it synthesize them by reusing page table pages that map zeros?
IIRC, we only ever fill single PMDs, even though we could gang a pmd
page up and do it for 1GB areas too.
I guess the page table consumption could really suck if we had code all
over the 57-bit address space and that code moved around and the process
ran for a long long time. Pathologically, we need a ulong/pmd_t for
each 2MB of address space which is 8*2^56-30=512GB per process. Yikes.
Right now, we'd at least detect the memory consumption and OOM-kill the
process(es) eventually. But, that's not really _this_ patch's problem.
It's a general problem, and doesn't even require the zero page to be
mapped all over.
Longer-term, I'd much rather see us add some page table reclaim
mechanism that new how to go after things like excessive page tables in
MAP_NORESERVE areas.
^ permalink raw reply
* Re: [PATCH 16/22] docs: gpio: driver.rst: fix a bad tag
From: Linus Walleij @ 2019-06-07 20:57 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab,
linux-kernel@vger.kernel.org, Jonathan Corbet,
Bartosz Golaszewski, open list:GPIO SUBSYSTEM
In-Reply-To: <ab694e03ba6de8908d0a19a58408180eee3f795b.1559171394.git.mchehab+samsung@kernel.org>
On Thu, May 30, 2019 at 1:24 AM Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
> With ReST, [foo]_ means a reference to foo, causing this warning:
>
> Documentation/driver-api/gpio/driver.rst:419: WARNING: Unknown target name: "devm".
>
> Fix it by using a literal for the name.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Patch applied to the GPIO tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Andy Lutomirski @ 2019-06-07 20:43 UTC (permalink / raw)
To: Yu-cheng Yu
Cc: Dave Hansen, Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner,
Ingo Molnar, linux-kernel, linux-doc, linux-mm, linux-arch,
linux-api, Arnd Bergmann, Balbir Singh, Borislav Petkov,
Cyrill Gorcunov, Dave Hansen, Eugene Syromiatnikov,
Florian Weimer, H.J. Lu, Jann Horn, Jonathan Corbet, Kees Cook,
Mike Kravetz, Nadav Amit, Oleg Nesterov, Pavel Machek,
Randy Dunlap, Ravi V. Shankar, Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <7e0b97bf1fbe6ff20653a8e4e147c6285cc5552d.camel@intel.com>
> On Jun 7, 2019, at 12:49 PM, Yu-cheng Yu <yu-cheng.yu@intel.com> wrote:
>
> On Fri, 2019-06-07 at 11:29 -0700, Andy Lutomirski wrote:
>>> On Jun 7, 2019, at 10:59 AM, Dave Hansen <dave.hansen@intel.com> wrote:
>>>
>>>> On 6/7/19 10:43 AM, Peter Zijlstra wrote:
>>>> I've no idea what the kernel should do; since you failed to answer the
>>>> question what happens when you point this to garbage.
>>>>
>>>> Does it then fault or what?
>>>
>>> Yeah, I think you'll fault with a rather mysterious CR2 value since
>>> you'll go look at the instruction that faulted and not see any
>>> references to the CR2 value.
>>>
>>> I think this new MSR probably needs to get included in oops output when
>>> CET is enabled.
>>
>> This shouldn’t be able to OOPS because it only happens at CPL 3, right? We
>> should put it into core dumps, though.
>>
>>>
>>> Why don't we require that a VMA be in place for the entire bitmap?
>>> Don't we need a "get" prctl function too in case something like a JIT is
>>> running and needs to find the location of this bitmap to set bits itself?
>>>
>>> Or, do we just go whole-hog and have the kernel manage the bitmap
>>> itself. Our interface here could be:
>>>
>>> prctl(PR_MARK_CODE_AS_LEGACY, start, size);
>>>
>>> and then have the kernel allocate and set the bitmap for those code
>>> locations.
>>
>> Given that the format depends on the VA size, this might be a good idea. I
>> bet we can reuse the special mapping infrastructure for this — the VMA could
>> be a MAP_PRIVATE special mapping named [cet_legacy_bitmap] or similar, and we
>> can even make special rules to core dump it intelligently if needed. And we
>> can make mremap() on it work correctly if anyone (CRIU?) cares.
>>
>> Hmm. Can we be creative and skip populating it with zeros? The CPU should
>> only ever touch a page if we miss an ENDBR on it, so, in normal operation, we
>> don’t need anything to be there. We could try to prevent anyone from
>> *reading* it outside of ENDBR tracking if we want to avoid people accidentally
>> wasting lots of memory by forcing it to be fully populated when the read it.
>>
>> The one downside is this forces it to be per-mm, but that seems like a
>> generally reasonable model anyway.
>>
>> This also gives us an excellent opportunity to make it read-only as seen from
>> userspace to prevent exploits from just poking it full of ones before
>> redirecting execution.
>
> GLIBC sets bits only for legacy code, and then makes the bitmap read-only. That
> avoids most issues:
How does glibc know the linear address space size? We don’t want LA64 to break old binaries because the address calculation changed.
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Andy Lutomirski @ 2019-06-07 20:40 UTC (permalink / raw)
To: Dave Hansen
Cc: Peter Zijlstra, Yu-cheng Yu, x86, H. Peter Anvin, Thomas Gleixner,
Ingo Molnar, linux-kernel, linux-doc, linux-mm, linux-arch,
linux-api, Arnd Bergmann, Balbir Singh, Borislav Petkov,
Cyrill Gorcunov, Dave Hansen, Eugene Syromiatnikov,
Florian Weimer, H.J. Lu, Jann Horn, Jonathan Corbet, Kees Cook,
Mike Kravetz, Nadav Amit, Oleg Nesterov, Pavel Machek,
Randy Dunlap, Ravi V. Shankar, Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <352e6172-938d-f8e4-c195-9fd1b881bdee@intel.com>
> On Jun 7, 2019, at 11:58 AM, Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 6/7/19 11:29 AM, Andy Lutomirski wrote:
> ...
>>> I think this new MSR probably needs to get included in oops output when
>>> CET is enabled.
>>
>> This shouldn’t be able to OOPS because it only happens at CPL 3,
>> right? We should put it into core dumps, though.
>
> Good point.
>
> Yu-cheng, can you just confirm that the bitmap can't be referenced in
> ring-0, no matter what? We should also make sure that no funny business
> happens if we put an address in the bitmap that faults, or is
> non-canonical. Do we have any self-tests for that?
>
> Let's say userspace gets a fault on this. Do they have the
> introspection capability to figure out why they faulted, say in their
> signal handler?
We need to stick the tracker state in the sigcontext somewhere.
Did we end up defining a signal frame shadow stack token?
>
>>> Why don't we require that a VMA be in place for the entire bitmap?
>>> Don't we need a "get" prctl function too in case something like a JIT is
>>> running and needs to find the location of this bitmap to set bits itself?
>>>
>>> Or, do we just go whole-hog and have the kernel manage the bitmap
>>> itself. Our interface here could be:
>>>
>>> prctl(PR_MARK_CODE_AS_LEGACY, start, size);
>>>
>>> and then have the kernel allocate and set the bitmap for those code
>>> locations.
>>
>> Given that the format depends on the VA size, this might be a good
>> idea.
>
> Yeah, making userspace know how large the address space is or could be
> is rather nasty, especially if we ever get any fancy CPU features that
> eat up address bits (a la ARM top-byte-ignore or SPARC ADI).
That gets extra bad if we ever grow user code that uses it but is unaware. It could poke the wrong part of the bitmap.
>
>> Hmm. Can we be creative and skip populating it with zeros? The CPU
> should only ever touch a page if we miss an ENDBR on it, so, in normal
> operation, we don’t need anything to be there. We could try to prevent
> anyone from *reading* it outside of ENDBR tracking if we want to avoid
> people accidentally wasting lots of memory by forcing it to be fully
> populated when the read it.
>
> Won't reads on a big, contiguous private mapping get the huge zero page
> anyway?
The zero pages may be free, but the page tables could be decently large. Does the core mm code use huge, immense, etc huge zero pages? Or can it synthesize them by reusing page table pages that map zeros?
>
>> The one downside is this forces it to be per-mm, but that seems like
>> a generally reasonable model anyway.
>
> Yeah, practically, you could only make it shared if you shared the
> layout of all code in the address space. I'm sure the big database(s)
> do that cross-process, but I bet nobody else does. User ASLR
> practically guarantees that nobody can do this.
I meant per-mm instead of per-task.
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Yu-cheng Yu @ 2019-06-07 20:06 UTC (permalink / raw)
To: Dave Hansen, Andy Lutomirski
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <4b448cde-ee4e-1c95-0f7f-4fe694be7db6@intel.com>
On Fri, 2019-06-07 at 13:00 -0700, Dave Hansen wrote:
> On 6/7/19 12:49 PM, Yu-cheng Yu wrote:
> > >
> > > This also gives us an excellent opportunity to make it read-only as seen
> > > from
> > > userspace to prevent exploits from just poking it full of ones before
> > > redirecting execution.
> >
> > GLIBC sets bits only for legacy code, and then makes the bitmap read-
> > only. That
> > avoids most issues:
> >
> > To populate bitmap pages, mprotect() is required.
> > Reading zero bitmap pages would not waste more physical memory, right?
>
> Huh, how does glibc know about all possible past and future legacy code
> in the application?
When dlopen() gets a legacy binary and the policy allows that, it will manage
the bitmap:
If a bitmap has not been created, create one.
Set bits for the legacy code being loaded.
Yu-cheng
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Yu-cheng Yu @ 2019-06-07 19:56 UTC (permalink / raw)
To: Dave Hansen, Andy Lutomirski
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <352e6172-938d-f8e4-c195-9fd1b881bdee@intel.com>
On Fri, 2019-06-07 at 11:58 -0700, Dave Hansen wrote:
> On 6/7/19 11:29 AM, Andy Lutomirski wrote:
> ...
> > > I think this new MSR probably needs to get included in oops output when
> > > CET is enabled.
> >
> > This shouldn’t be able to OOPS because it only happens at CPL 3,
> > right? We should put it into core dumps, though.
>
> Good point.
>
> Yu-cheng, can you just confirm that the bitmap can't be referenced in
> ring-0, no matter what? We should also make sure that no funny business
> happens if we put an address in the bitmap that faults, or is
> non-canonical. Do we have any self-tests for that?
Yes, the bitmap is user memory, but the kernel can still get to it (e.g.
copy_from_user()). We can do more check on the address.
>
> Let's say userspace gets a fault on this. Do they have the
> introspection capability to figure out why they faulted, say in their
> signal handler?
The bitmap address is kept by the application; the kernel won't provide it again
to user-space. In the signal handler, the app can find out from its own record.
[...]
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Dave Hansen @ 2019-06-07 20:00 UTC (permalink / raw)
To: Yu-cheng Yu, Andy Lutomirski
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <7e0b97bf1fbe6ff20653a8e4e147c6285cc5552d.camel@intel.com>
On 6/7/19 12:49 PM, Yu-cheng Yu wrote:
>>
>> This also gives us an excellent opportunity to make it read-only as seen from
>> userspace to prevent exploits from just poking it full of ones before
>> redirecting execution.
> GLIBC sets bits only for legacy code, and then makes the bitmap read-only. That
> avoids most issues:
>
> To populate bitmap pages, mprotect() is required.
> Reading zero bitmap pages would not waste more physical memory, right?
Huh, how does glibc know about all possible past and future legacy code
in the application?
^ 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