* Re: [PATCH] docs/memory-barriers.txt: Fix broken DMA vs MMIO ordering example
From: Tony Luck @ 2018-03-28 17:57 UTC (permalink / raw)
To: Sinan Kaya
Cc: Paul McKenney, Will Deacon, linux-kernel@vger.kernel.org,
linux-doc, Benjamin Herrenschmidt, Arnd Bergmann, Jason Gunthorpe,
Peter Zijlstra, Ingo Molnar, Jonathan Corbet,
linux-ia64@vger.kernel.org
In-Reply-To: <c93ed5db-8cfd-1258-3396-62ca2076c44d@codeaurora.org>
On Wed, Mar 28, 2018 at 6:02 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
> +linux-ia64
> Does IA64 follow this requirement? If not, is implementation planned?
>
> "no wmb() before writel()"
>
> Linus asked us to get rid of wmb() in front of writel() for UC memory.
> Just checking that we are not breaking anything for IA64.
We should be OK on ia64, writel() uses a cast to:
*(volatile unsigned int __force *)
which the compiler takes as a request to use a "st4.rel" instruction
(meaning "store with release semantics"). So the value stored will
be visible to anything that follows.
-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 05/11] dt-bindings: i3c: Document core bindings
From: Boris Brezillon @ 2018-03-28 17:28 UTC (permalink / raw)
To: Rob Herring
Cc: Wolfram Sang, Linux I2C, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
linux-kernel@vger.kernel.org, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, linux-gpio, Boris Brezillon
In-Reply-To: <CAL_JsqKKf_Ob6AUvO5xgEFzSWakYDuPPzVKe4taoN1kzw3b1fQ@mail.gmail.com>
On Wed, 28 Mar 2018 11:42:07 -0500
Rob Herring <robh@kernel.org> wrote:
> >>
> >> > +where device-type is describing the type of device connected on the bus
> >> > +(gpio-controller, sensor, ...).
> >> > +
> >> > +Required properties
> >> > +-------------------
> >> > +- reg: contains 3 cells
> >> > + + first cell : encodes the I2C address. Should be 0 if the device does not
> >> > + have one (0 is not a valid I3C address).
> >>
> >> Change here to "encodes the static I2C address".
> >>
> >> 0 is not a valid I2C address?
> >
> > According to [1] it is reserved, and it's reserved in the I3C spec
> > anyway (see "Table 9 I3C Slave Address Restrictions" in the I3C spec).
>
> Sorry, what I meant was s/I3C/I2C/. The first cell is I2C address and
> 0 is not valid.
Okay, got it now :-).
>
> >> > +
> >> > + + second and third cells: should encode the ProvisionalID. The second cell
> >> > + contains the manufacturer ID left-shifted by 1.
> >> > + The third cell contains ORing of the part ID
> >> > + left-shifted by 16, the instance ID left-shifted
> >> > + by 12 and the extra information. This encoding is
> >> > + following the PID definition provided by the I3C
> >> > + specification.
> >
> > One extra question for you: should I refer to the I3C_DEV(),
> > I3C_DEV_WITH_STATIC_ADDR() and I2C_DEV() macros in the bindings doc?
> > And if I do, should I use them my example?
>
> Well, I don't want to see "device@I3C_DEV(...)" for unit-addresses.
That wouldn't work anyway.
> You can use them for reg property, but it's somewhat pointless to use
> it in one place and not the other.
Not sure I follow you. These macros have been added to ease definitions
of reg, but you'll still have to manually define the unit-address
manually. Are you saying I should not use them in dts files or just that
I should not mention it in the doc. If this is the former, then patch 6
should be dropped.
--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 05/11] dt-bindings: i3c: Document core bindings
From: Rob Herring @ 2018-03-28 16:42 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, Linux I2C, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
linux-kernel@vger.kernel.org, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, linux-gpio, Boris Brezillon
In-Reply-To: <20180328101922.22a7039d@bbrezillon>
On Wed, Mar 28, 2018 at 3:19 AM, Boris Brezillon
<boris.brezillon@bootlin.com> wrote:
> Hi Rob,
>
> On Mon, 26 Mar 2018 17:24:58 -0500
> Rob Herring <robh@kernel.org> wrote:
>
>> > +
>> > +I3C devices
>> > +===========
>> > +
>> > +All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
>> > +are thus discoverable. So, by default, I3C devices do not have to be described
>> > +in the device tree.
>> > +This being said, one might want to attach extra resources to these devices,
>> > +and those resources may have to be described in the device tree, which in turn
>> > +means we have to describe I3C devices.
>> > +
>> > +Another use case for describing an I3C device in the device tree is when this
>> > +I3C device has a static address and we want to assign it a specific dynamic
>> > +address before the DAA takes place (so that other devices on the bus can't
>>
>> static is I2C address and dynamic is an I3C address. That could be
>> clearer throughout.
>
> I'll clarify that.
>
>>
>> > +take this dynamic address).
>> > +
>> > +The I3C device should be names <device-type>@<static-address>,<i3c-pid>,
>>
>> s/static-address/static-i2c-address/
>
> Okay.
>
>>
>> > +where device-type is describing the type of device connected on the bus
>> > +(gpio-controller, sensor, ...).
>> > +
>> > +Required properties
>> > +-------------------
>> > +- reg: contains 3 cells
>> > + + first cell : encodes the I2C address. Should be 0 if the device does not
>> > + have one (0 is not a valid I3C address).
>>
>> Change here to "encodes the static I2C address".
>>
>> 0 is not a valid I2C address?
>
> According to [1] it is reserved, and it's reserved in the I3C spec
> anyway (see "Table 9 I3C Slave Address Restrictions" in the I3C spec).
Sorry, what I meant was s/I3C/I2C/. The first cell is I2C address and
0 is not valid.
>> > +
>> > + + second and third cells: should encode the ProvisionalID. The second cell
>> > + contains the manufacturer ID left-shifted by 1.
>> > + The third cell contains ORing of the part ID
>> > + left-shifted by 16, the instance ID left-shifted
>> > + by 12 and the extra information. This encoding is
>> > + following the PID definition provided by the I3C
>> > + specification.
>
> One extra question for you: should I refer to the I3C_DEV(),
> I3C_DEV_WITH_STATIC_ADDR() and I2C_DEV() macros in the bindings doc?
> And if I do, should I use them my example?
Well, I don't want to see "device@I3C_DEV(...)" for unit-addresses.
You can use them for reg property, but it's somewhat pointless to use
it in one place and not the other.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 4/8] dt-bindings: Add doc for the Ingenic TCU drivers
From: Rob Herring @ 2018-03-28 16:28 UTC (permalink / raw)
To: Paul Cercueil
Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Lee Jones,
Daniel Lezcano, Ralf Baechle, Jonathan Corbet, Mark Rutland,
James Hogan, Maarten ter Huurne, linux-clk, devicetree,
linux-kernel@vger.kernel.org, Linux-MIPS, linux-doc
In-Reply-To: <3765e5a86b80b2a1888cabee623e5d0c@crapouillou.net>
On Wed, Mar 28, 2018 at 10:33 AM, Paul Cercueil <paul@crapouillou.net> wrote:
> Le 2018-03-27 16:46, Rob Herring a écrit :
>>
>> On Sun, Mar 18, 2018 at 12:28:57AM +0100, Paul Cercueil wrote:
>>>
>>> Add documentation about how to properly use the Ingenic TCU
>>> (Timer/Counter Unit) drivers from devicetree.
>>>
>>> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
>>> ---
>>> .../bindings/clock/ingenic,tcu-clocks.txt | 42 ++++++++++++++++
>>> .../bindings/interrupt-controller/ingenic,tcu.txt | 39 +++++++++++++++
>>> .../devicetree/bindings/mfd/ingenic,tcu.txt | 56
>>> ++++++++++++++++++++++
>>> .../devicetree/bindings/timer/ingenic,tcu.txt | 41 ++++++++++++++++
>>> 4 files changed, 178 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
>>> create mode 100644
>>> Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
>>> create mode 100644 Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
>>> create mode 100644
>>> Documentation/devicetree/bindings/timer/ingenic,tcu.txt
>>>
>>> v4: New patch in this series. Corresponds to V2 patches 3-4-5 with
>>> added content.
>>> +/ {
>>> + tcu: mfd@10002000 {
>>> + compatible = "ingenic,tcu", "simple-mfd", "syscon";
>>> + reg = <0x10002000 0x1000>;
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + ranges = <0x0 0x10002000 0x1000>;
>>> +
>>> + tcu_timer: timer@10 {
>>> + compatible = "ingenic,jz4740-tcu";
>>> + reg = <0x10 0xff0>;
>>> +
>>> + clocks = <&tcu_clk 0>, <&tcu_clk 1>, <&tcu_clk
>>> 2>, <&tcu_clk 3>,
>>> + <&tcu_clk 4>, <&tcu_clk 5>,
>>> <&tcu_clk 6>, <&tcu_clk 7>;
>>> + clock-names = "timer0", "timer1", "timer2",
>>> "timer3",
>>> + "timer4", "timer5",
>>> "timer6", "timer7";
>>> +
>>> + interrupt-parent = <&tcu_irq>;
>>> + interrupts = <0 1 2 3 4 5 6 7>;
>>
>>
>> Thinking about this some more... You simply have 8 timers (and no other
>> functions?) with some internal clock and irq controls for each timer. I
>> don't think it really makes sense to create separate clock and irq
>> drivers in that case. That would be like creating clock drivers for
>> every clock divider in timers, pwms, uarts, etc. Unless the clocks get
>> exposed to other parts of the system, then there is no point.
>
>
> I have 8 timers with some internal clock and IRQ controls, that can be used
> as PWM.
Please include how you plan to do the PWM support too. I need a
complete picture of the h/w, not piecemeal, evolving bindings.
> But the TCU also controls the IRQ of the OS Timer (which is
> separate),
> as well as masking of the clocks for the OS timer and the watchdog.
The OS timer and watchdog are different blocks outside the TCU? This
doesn't seem to be the case based on the register definitions.
> I thought having clean drivers for different frameworks working on the same
> regmap was cleaner than having one big-ass driver handling everything.
DT is not the only way to instantiate drivers and how one OS splits
drivers should not define your DT binding. An MFD driver can create
child devices and a single DT node can be a provider of multiple
things. It is appropriate for an MFD to have child nodes primarily
when the sub devices need their own resources defined as properties in
DT or when the sub device is an IP block reused in multiple devices.
Just to have a node per driver/provider is not what should drive the
decision.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 7/8] clocksource: Add a new timer-ingenic driver
From: Daniel Lezcano @ 2018-03-28 16:25 UTC (permalink / raw)
To: Paul Cercueil
Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Lee Jones,
Ralf Baechle, Rob Herring, Jonathan Corbet, Mark Rutland,
James Hogan, Maarten ter Huurne, linux-clk, devicetree,
linux-kernel, linux-mips, linux-doc
In-Reply-To: <06976e4ae275c4cc0bddacc5e0c0c9a9@crapouillou.net>
On 28/03/2018 17:15, Paul Cercueil wrote:
> Le 2018-03-24 07:26, Daniel Lezcano a écrit :
>> On 18/03/2018 00:29, Paul Cercueil wrote:
>>> This driver will use the TCU (Timer Counter Unit) present on the Ingenic
>>> JZ47xx SoCs to provide the kernel with a clocksource and timers.
>>
>> Please provide a more detailed description about the timer.
>
> There's a doc file for that :)
Usually, when there is a new driver I ask for a description in the
changelog for reference.
>> Where is the clocksource ?
>
> Right, there is no clocksource, just timers.
>
>> I don't see the point of using channel idx and pwm checking here.
>>
>> There is one clockevent, why create multiple channels ? Can't you stick
>> to the usual init routine for a timer.
>
> So the idea is that we use all the TCU channels that won't be used for PWM
> as timers. Hence the PWM checking. Why is this bad?
It is not bad but arguable. By checking the channels used by the pwm in
the code, you introduce an adherence between two subsystems even if it
is just related to the DT parsing part.
As it is not needed to have more than one timer in the time framework
(at least with the same characteristics), the pwm channels check is
pointless. We can assume the author of the DT file is smart enough to
prevent conflicts and define a pwm and a timer properly instead of
adding more code complexity.
In addition, simplifying the code will allow you to use the timer-of
code and reduce very significantly the init function.
>>> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
>>> ---
>>> drivers/clocksource/Kconfig | 8 ++
>>> drivers/clocksource/Makefile | 1 +
>>> drivers/clocksource/timer-ingenic.c | 278
>>> ++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 287 insertions(+)
>>> create mode 100644 drivers/clocksource/timer-ingenic.c
>>>
>>> v2: Use SPDX identifier for the license
>>> v3: - Move documentation to its own patch
>>> - Search the devicetree for PWM clients, and use all the TCU
>>> channels that won't be used for PWM
>>> v4: - Add documentation about why we search for PWM clients
>>> - Verify that the PWM clients are for the TCU PWM driver
>>>
>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>> index d2e5382821a4..481422145fb4 100644
>>> --- a/drivers/clocksource/Kconfig
>>> +++ b/drivers/clocksource/Kconfig
>>> @@ -592,4 +592,12 @@ config CLKSRC_ST_LPC
>>> Enable this option to use the Low Power controller timer
>>> as clocksource.
>>>
>>> +config INGENIC_TIMER
>>> + bool "Clocksource/timer using the TCU in Ingenic JZ SoCs"
>>> + depends on MACH_INGENIC || COMPILE_TEST
>>
>> bool "Clocksource/timer using the TCU in Ingenic JZ SoCs" if COMPILE_TEST
>>
>> Remove the depends MACH_INGENIC.
>
> This driver is not useful on anything else than Ingenic SoCs, why should I
> remove MACH_INGENIC then?
For COMPILE_TEST on x86.
>>> + select CLKSRC_OF
>>> + default y
>>
>> No default, Kconfig platform selects the timer.
>
> Alright.
[ ... ]
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] Documentation/usb: Fix dead links and convert others to https
From: Sanjeev Gupta @ 2018-03-28 16:07 UTC (permalink / raw)
To: corbet, gregkh; +Cc: linux-doc, linux-kernel
All links checked, for those dead, I have replaced with copies on
archive.org. For some, https is not supported, http has been
kept.
The git log says this was last done by Justin P. Mattock in 2010.
Hi, Justin!
Signed-off-by: Sanjeev Gupta <ghane0@gmail.com>
---
Documentation/usb/usb-serial.txt | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt
index 349f3104fa4f..1c5c1da4f54e 100644
--- a/Documentation/usb/usb-serial.txt
+++ b/Documentation/usb/usb-serial.txt
@@ -83,7 +83,7 @@ HandSpring Visor, Palm USB, and Clié USB driver
parameters. e.g. modprobe visor vendor=0x54c product=0x66
There is a webpage and mailing lists for this portion of the driver at:
- http://sourceforge.net/projects/usbvisor/
+ https://sourceforge.net/projects/usbvisor/
For any questions or problems with this driver, please contact Greg
Kroah-Hartman at greg@kroah.com
@@ -105,15 +105,16 @@ PocketPC PDA Driver
kbytes/sec for download/upload to my iPAQ.
This driver is only one of a set of components required to utilize
- the USB connection. Please visit http://synce.sourceforge.net which
+ the USB connection. Please visit https://synce.sourceforge.net which
contains the necessary packages and a simple step-by-step howto.
Once connected, you can use Win CE programs like ftpView, Pocket Outlook
from the PDA and xcerdisp, synce utilities from the Linux side.
To use Pocket IE, follow the instructions given at
- http://www.tekguru.co.uk/EM500/usbtonet.htm to achieve the same thing
- on Win98. Omit the proxy server part; Linux is quite capable of forwarding
+ https://web.archive.org/web/20030415065014/http://www.tekguru.co.uk:80/EM500/usbtonet.htm
+ to achieve the same thing on Win98.
+ Omit the proxy server part; Linux is quite capable of forwarding
packets unlike Win98. Another modification is required at least for the
iPAQ - disable autosync by going to the Start/Settings/Connections menu
and unchecking the "Automatically synchronize ..." box. Go to
@@ -184,7 +185,7 @@ Keyspan USA-series Serial Adapters
functionality.
More information is available at:
- http://www.carnationsoftware.com/carnation/Keyspan.html
+ https://www.carnationsoftware.com/carnation/Keyspan.html
For any questions or problems with this driver, please contact Hugh
Blemings at hugh@misc.nu
@@ -436,7 +437,8 @@ Winchiphead CH341 Driver
also implements an IEEE 1284 parallel port, I2C and SPI, but that is not
supported by the driver. The protocol was analyzed from the behaviour
of the Windows driver, no datasheet is available at present.
- The manufacturer's website: http://www.winchiphead.com/.
+ The manufacturer's website:
+ https://web.archive.org/web/20170911133726/http://winchiphead.com/ .
For any questions or problems with this driver, please contact
frank@kingswood-consulting.co.uk.
--
2.15.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v4 4/8] dt-bindings: Add doc for the Ingenic TCU drivers,
From: Paul Cercueil @ 2018-03-28 15:33 UTC (permalink / raw)
To: Rob Herring
Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Lee Jones,
Daniel Lezcano, Ralf Baechle, Jonathan Corbet, Mark Rutland,
James Hogan, Maarten ter Huurne, linux-clk, devicetree,
linux-kernel, linux-mips, linux-doc
In-Reply-To: <20180327144631.j2bugsjxulkv57ws@rob-hp-laptop>
Le 2018-03-27 16:46, Rob Herring a écrit :
> On Sun, Mar 18, 2018 at 12:28:57AM +0100, Paul Cercueil wrote:
>> Add documentation about how to properly use the Ingenic TCU
>> (Timer/Counter Unit) drivers from devicetree.
>>
>> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
>> ---
>> .../bindings/clock/ingenic,tcu-clocks.txt | 42
>> ++++++++++++++++
>> .../bindings/interrupt-controller/ingenic,tcu.txt | 39
>> +++++++++++++++
>> .../devicetree/bindings/mfd/ingenic,tcu.txt | 56
>> ++++++++++++++++++++++
>> .../devicetree/bindings/timer/ingenic,tcu.txt | 41
>> ++++++++++++++++
>> 4 files changed, 178 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
>> create mode 100644
>> Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
>> create mode 100644
>> Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
>> create mode 100644
>> Documentation/devicetree/bindings/timer/ingenic,tcu.txt
>>
>> v4: New patch in this series. Corresponds to V2 patches 3-4-5 with
>> added content.
>>
>> diff --git
>> a/Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
>> b/Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
>> new file mode 100644
>> index 000000000000..471d27078599
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
>> @@ -0,0 +1,42 @@
>> +Ingenic SoC TCU binding
>> +
>> +The TCU is the Timer/Counter Unit present in all Ingenic SoCs. It
>> features 8
>> +channels, each one having its own clock, that can be started and
>> stopped,
>> +reparented, and reclocked.
>> +
>> +Required properties:
>> +- compatible : One of:
>> + * ingenic,jz4740-tcu-clocks,
>> + * ingenic,jz4770-tcu-clocks,
>> + * ingenic,jz4780-tcu-clocks.
>> +- clocks : List of phandle & clock specifiers for clocks external to
>> the TCU.
>> + The "pclk", "rtc" and "ext" clocks should be provided.
>> +- clock-names : List of name strings for the external clocks.
>> +- #clock-cells: Should be 1.
>> + Clock consumers specify this argument to identify a clock. The
>> valid values
>> + may be found in <dt-bindings/clock/ingenic,tcu.h>.
>> +
>> +Example:
>
> Let's just put one complete example in instead of all these duplicated
> and incomplete examples.
Alright.
>> +
>> +/ {
>> + tcu: mfd@10002000 {
>> + compatible = "ingenic,tcu", "simple-mfd", "syscon";
>> + reg = <0x10002000 0x1000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x0 0x10002000 0x1000>;
>> +
>> + tcu_clk: clocks@10 {
>> + compatible = "ingenic,jz4740-tcu-clocks";
>> + reg = <0x10 0xff0>;
>> +
>> + clocks = <&ext>, <&rtc>, <&pclk>;
>> + clock-names = "ext", "rtc", "pclk";
>> +
>> + #clock-cells = <1>;
>> + };
>> + };
>> +};
>> +
>> +For information about the top-level "ingenic,tcu" compatible node and
>> other
>> +children nodes, see
>> Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
>> diff --git
>> a/Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
>> b/Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
>> new file mode 100644
>> index 000000000000..7f3af2da77cd
>> --- /dev/null
>> +++
>> b/Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
>> @@ -0,0 +1,39 @@
>> +Ingenic SoCs Timer/Counter Unit Interrupt Controller
>> +
>> +Required properties:
>> +
>> +- compatible : should be "ingenic,<socname>-tcu-intc". Valid strings
>> are:
>> + * ingenic,jz4740-tcu-intc
>> + * ingenic,jz4770-tcu-intc
>> + * ingenic,jz4780-tcu-intc
>> +- interrupt-controller : Identifies the node as an interrupt
>> controller
>> +- #interrupt-cells : Specifies the number of cells needed to encode
>> an
>> + interrupt source. The value shall be 1.
>> +- interrupt-parent : phandle of the interrupt controller.
>> +- interrupts : Specifies the interrupt the controller is connected
>> to.
>> +
>> +Example:
>> +
>> +/ {
>> + tcu: mfd@10002000 {
>> + compatible = "ingenic,tcu", "simple-mfd", "syscon";
>> + reg = <0x10002000 0x1000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x0 0x10002000 0x1000>;
>> +
>> + tcu_irq: interrupt-controller@20 {
>> + compatible = "ingenic,jz4740-tcu-intc";
>> + reg = <0x20 0x20>;
>> +
>> + interrupt-controller;
>> + #interrupt-cells = <1>;
>> +
>> + interrupt-parent = <&intc>;
>> + interrupts = <15>;
>
> The interrupt controller doesn't require any clocks?
It doesn't. The TCU registers not related to TCU channels are always
active.
>> + };
>> + };
>> +};
>> +
>> +For information about the top-level "ingenic,tcu" compatible node and
>> other
>> +children nodes, see
>> Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
>> diff --git a/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
>> b/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
>> new file mode 100644
>> index 000000000000..5742c3f21550
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
>> @@ -0,0 +1,56 @@
>> +Ingenic JZ47xx SoCs Timer/Counter Unit devicetree bindings
>> +----------------------------------------------------------
>> +
>> +For a description of the TCU hardware and drivers, have a look at
>> +Documentation/mips/ingenic-tcu.txt.
>> +
>> +The TCU is implemented as a parent node, whose role is to create the
>> +regmap, and child nodes for the various drivers listed in the
>> aforementioned
>> +document.
>> +
>> +Required properties:
>> +
>> +- compatible: must be "ingenic,tcu", "simple-mfd", "syscon";
>> +- reg: Should be the offset/length value corresponding to the TCU
>> registers
>> +- #address-cells: Should be <1>;
>> +- #size-cells: Should be <1>;
>> +- ranges: Should be one range for the full TCU registers area
>> +
>> +Accepted children nodes:
>> +-
>> Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
>> +- Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
>> +- Documentation/devicetree/bindings/timer/ingenic,tcu.txt
>> +
>> +
>> +Example:
>> +
>> +/ {
>> + tcu: mfd@10002000 {
>> + compatible = "ingenic,tcu", "simple-mfd", "syscon";
>> + reg = <0x10002000 0x1000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x0 0x10002000 0x1000>;
>> +
>> + tcu_irq: interrupt-controller@20 {
>> + compatible = "ingenic,jz4740-tcu-intc";
>> + reg = <0x20 0x20>;
>
> I think you should drop this node and make the parent node the
> interrupt
> controller. That is the normal pattern where the parent node handles
> all the common functions. Otherwise, there is no need to have the
> parent
> node. You should then also drop simple-mfd as then you can control
> initialization order by initializing interrupt controller before
> its clients.
Alright, good idea.
>> + ...
>> + };
>> +
>> + tcu_clk: clocks@10 {
>> + compatible = "ingenic,jz4740-tcu-clocks";
>> + reg = <0x10 0xff0>;
>> + ...
>> + };
>> +
>> + tcu_timer: timer@10 {
>> + compatible = "ingenic,jz4740-tcu";
>> + reg = <0x10 0xff0>;
>
> Is this copy-n-paste or you really have 2 nodes at the same address?
> The
> latter is not valid.
I do have 2 nodes at the same address...
>> + ...
>> + };
>> + };
>> +};
>> +
>> +For more information about the children node, refer to the documents
>> listed
>> +above in the "Accepted children nodes" section.
>> diff --git a/Documentation/devicetree/bindings/timer/ingenic,tcu.txt
>> b/Documentation/devicetree/bindings/timer/ingenic,tcu.txt
>> new file mode 100644
>> index 000000000000..f910b7e96783
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/timer/ingenic,tcu.txt
>> @@ -0,0 +1,41 @@
>> +Ingenic JZ47xx SoCs Timer/Counter Unit driver
>> +---------------------------------------------
>> +
>> +Required properties:
>> +
>> +- compatible : should be "ingenic,<socname>-tcu". Valid strings are:
>> + * ingenic,jz4740-tcu
>> + * ingenic,jz4770-tcu
>> + * ingenic,jz4780-tcu
>> +- interrupt-parent : phandle of the TCU interrupt controller.
>> +- interrupts : Specifies the interrupts the controller is connected
>> to.
>> +- clocks : List of phandle & clock specifiers for the TCU clocks.
>> +- clock-names : List of name strings for the TCU clocks.
>> +
>> +Example:
>> +
>> +/ {
>> + tcu: mfd@10002000 {
>> + compatible = "ingenic,tcu", "simple-mfd", "syscon";
>> + reg = <0x10002000 0x1000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x0 0x10002000 0x1000>;
>> +
>> + tcu_timer: timer@10 {
>> + compatible = "ingenic,jz4740-tcu";
>> + reg = <0x10 0xff0>;
>> +
>> + clocks = <&tcu_clk 0>, <&tcu_clk 1>, <&tcu_clk 2>, <&tcu_clk 3>,
>> + <&tcu_clk 4>, <&tcu_clk 5>, <&tcu_clk 6>, <&tcu_clk 7>;
>> + clock-names = "timer0", "timer1", "timer2", "timer3",
>> + "timer4", "timer5", "timer6", "timer7";
>> +
>> + interrupt-parent = <&tcu_irq>;
>> + interrupts = <0 1 2 3 4 5 6 7>;
>
> Thinking about this some more... You simply have 8 timers (and no other
> functions?) with some internal clock and irq controls for each timer. I
> don't think it really makes sense to create separate clock and irq
> drivers in that case. That would be like creating clock drivers for
> every clock divider in timers, pwms, uarts, etc. Unless the clocks get
> exposed to other parts of the system, then there is no point.
I have 8 timers with some internal clock and IRQ controls, that can be
used
as PWM. But the TCU also controls the IRQ of the OS Timer (which is
separate),
as well as masking of the clocks for the OS timer and the watchdog.
I thought having clean drivers for different frameworks working on the
same
regmap was cleaner than having one big-ass driver handling everything.
>> + };
>> + };
>> +};
>> +
>> +For information about the top-level "ingenic,tcu" compatible node and
>> other
>> +children nodes, see
>> Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
>> --
>> 2.11.0
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 7/8] clocksource: Add a new timer-ingenic driver,
From: Paul Cercueil @ 2018-03-28 15:15 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Lee Jones,
Ralf Baechle, Rob Herring, Jonathan Corbet, Mark Rutland,
James Hogan, Maarten ter Huurne, linux-clk, devicetree,
linux-kernel, linux-mips, linux-doc
In-Reply-To: <a8d28b2b-4e40-83b9-d65e-beecbd36ad33@linaro.org>
Le 2018-03-24 07:26, Daniel Lezcano a écrit :
> On 18/03/2018 00:29, Paul Cercueil wrote:
>> This driver will use the TCU (Timer Counter Unit) present on the
>> Ingenic
>> JZ47xx SoCs to provide the kernel with a clocksource and timers.
>
> Please provide a more detailed description about the timer.
There's a doc file for that :)
> Where is the clocksource ?
Right, there is no clocksource, just timers.
> I don't see the point of using channel idx and pwm checking here.
>
> There is one clockevent, why create multiple channels ? Can't you stick
> to the usual init routine for a timer.
So the idea is that we use all the TCU channels that won't be used for
PWM
as timers. Hence the PWM checking. Why is this bad?
>> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
>> ---
>> drivers/clocksource/Kconfig | 8 ++
>> drivers/clocksource/Makefile | 1 +
>> drivers/clocksource/timer-ingenic.c | 278
>> ++++++++++++++++++++++++++++++++++++
>> 3 files changed, 287 insertions(+)
>> create mode 100644 drivers/clocksource/timer-ingenic.c
>>
>> v2: Use SPDX identifier for the license
>> v3: - Move documentation to its own patch
>> - Search the devicetree for PWM clients, and use all the TCU
>> channels that won't be used for PWM
>> v4: - Add documentation about why we search for PWM clients
>> - Verify that the PWM clients are for the TCU PWM driver
>>
>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>> index d2e5382821a4..481422145fb4 100644
>> --- a/drivers/clocksource/Kconfig
>> +++ b/drivers/clocksource/Kconfig
>> @@ -592,4 +592,12 @@ config CLKSRC_ST_LPC
>> Enable this option to use the Low Power controller timer
>> as clocksource.
>>
>> +config INGENIC_TIMER
>> + bool "Clocksource/timer using the TCU in Ingenic JZ SoCs"
>> + depends on MACH_INGENIC || COMPILE_TEST
>
> bool "Clocksource/timer using the TCU in Ingenic JZ SoCs" if
> COMPILE_TEST
>
> Remove the depends MACH_INGENIC.
This driver is not useful on anything else than Ingenic SoCs, why should
I
remove MACH_INGENIC then?
>> + select CLKSRC_OF
>> + default y
>
> No default, Kconfig platform selects the timer.
Alright.
>> + help
>> + Support for the timer/counter unit of the Ingenic JZ SoCs.
>> +
>> endmenu
>> diff --git a/drivers/clocksource/Makefile
>> b/drivers/clocksource/Makefile
>> index d6dec4489d66..98691e8999fe 100644
>> --- a/drivers/clocksource/Makefile
>> +++ b/drivers/clocksource/Makefile
>> @@ -74,5 +74,6 @@ obj-$(CONFIG_ASM9260_TIMER) += asm9260_timer.o
>> obj-$(CONFIG_H8300_TMR8) += h8300_timer8.o
>> obj-$(CONFIG_H8300_TMR16) += h8300_timer16.o
>> obj-$(CONFIG_H8300_TPU) += h8300_tpu.o
>> +obj-$(CONFIG_INGENIC_TIMER) += timer-ingenic.o
>> obj-$(CONFIG_CLKSRC_ST_LPC) += clksrc_st_lpc.o
>> obj-$(CONFIG_X86_NUMACHIP) += numachip.o
>> diff --git a/drivers/clocksource/timer-ingenic.c
>> b/drivers/clocksource/timer-ingenic.c
>> new file mode 100644
>> index 000000000000..8c777c0c0023
>> --- /dev/null
>> +++ b/drivers/clocksource/timer-ingenic.c
>> @@ -0,0 +1,278 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Ingenic JZ47xx SoC TCU clocksource driver
>> + * Copyright (C) 2018 Paul Cercueil <paul@crapouillou.net>
>> + */
>> +
>> +#include <linux/bitops.h>
>> +#include <linux/clk.h>
>> +#include <linux/clockchips.h>
>> +#include <linux/err.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/mfd/syscon.h>
>> +#include <linux/mfd/syscon/ingenic-tcu.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_irq.h>
>> +#include <linux/regmap.h>
>> +#include <linux/slab.h>
>> +
>> +#define NUM_CHANNELS 8
>> +
>> +struct ingenic_tcu;
>> +
>> +struct ingenic_tcu_channel {
>> + unsigned int idx;
>> + struct clk *clk;
>> +};
>> +
>> +struct ingenic_tcu {
>> + struct ingenic_tcu_channel channels[NUM_CHANNELS];
>> + unsigned long requested;
>> + struct regmap *map;
>> +};
>> +
>> +struct ingenic_clock_event_device {
>> + struct clock_event_device cevt;
>> + struct ingenic_tcu_channel *channel;
>> + char name[32];
>> +};
>> +
>> +#define ingenic_cevt(_evt) \
>> + container_of(_evt, struct ingenic_clock_event_device, cevt)
>> +
>> +static inline struct ingenic_tcu *to_ingenic_tcu(struct
>> ingenic_tcu_channel *ch)
>> +{
>> + return container_of(ch, struct ingenic_tcu, channels[ch->idx]);
>> +}
>> +
>> +static int ingenic_tcu_cevt_set_state_shutdown(struct
>> clock_event_device *evt)
>> +{
>> + struct ingenic_clock_event_device *jzcevt = ingenic_cevt(evt);
>> + struct ingenic_tcu_channel *channel = jzcevt->channel;
>> + struct ingenic_tcu *tcu = to_ingenic_tcu(channel);
>> + unsigned int idx = channel->idx;
>> +
>> + regmap_write(tcu->map, TCU_REG_TECR, BIT(idx));
>> + return 0;
>> +}
>> +
>> +static int ingenic_tcu_cevt_set_next(unsigned long next,
>> + struct clock_event_device *evt)
>> +{
>> + struct ingenic_clock_event_device *jzcevt = ingenic_cevt(evt);
>> + struct ingenic_tcu_channel *channel = jzcevt->channel;
>> + struct ingenic_tcu *tcu = to_ingenic_tcu(channel);
>> + unsigned int idx = channel->idx;
>> +
>> + if (next > 0xffff)
>> + return -EINVAL;
>> +
>> + regmap_write(tcu->map, TCU_REG_TDFRc(idx), (unsigned int) next);
>> + regmap_write(tcu->map, TCU_REG_TCNTc(idx), 0);
>> + regmap_write(tcu->map, TCU_REG_TESR, BIT(idx));
>> +
>> + return 0;
>> +}
>> +
>> +static irqreturn_t ingenic_tcu_cevt_cb(int irq, void *dev_id)
>> +{
>> + struct clock_event_device *cevt = dev_id;
>> + struct ingenic_clock_event_device *jzcevt = ingenic_cevt(cevt);
>> + struct ingenic_tcu_channel *channel = jzcevt->channel;
>> + struct ingenic_tcu *tcu = to_ingenic_tcu(channel);
>> + unsigned int idx = channel->idx;
>> +
>> + regmap_write(tcu->map, TCU_REG_TECR, BIT(idx));
>> +
>> + if (cevt->event_handler)
>> + cevt->event_handler(cevt);
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> +static int __init ingenic_tcu_req_channel(struct ingenic_tcu_channel
>> *channel)
>> +{
>> + struct ingenic_tcu *tcu = to_ingenic_tcu(channel);
>> + char buf[16];
>> + int err;
>> +
>> + if (test_and_set_bit(channel->idx, &tcu->requested))
>> + return -EBUSY;
>> +
>> + snprintf(buf, sizeof(buf), "timer%u", channel->idx);
>> + channel->clk = clk_get(NULL, buf);
>> + if (IS_ERR(channel->clk)) {
>> + err = PTR_ERR(channel->clk);
>> + goto out_release;
>> + }
>> +
>> + err = clk_prepare_enable(channel->clk);
>> + if (err)
>> + goto out_clk_put;
>> +
>> + return 0;
>> +
>> +out_clk_put:
>> + clk_put(channel->clk);
>> +out_release:
>> + clear_bit(channel->idx, &tcu->requested);
>> + return err;
>> +}
>> +
>> +static int __init ingenic_tcu_reset_channel(struct device_node *np,
>> + struct ingenic_tcu_channel *channel)
>> +{
>> + struct ingenic_tcu *tcu = to_ingenic_tcu(channel);
>> +
>> + return regmap_update_bits(tcu->map, TCU_REG_TCSRc(channel->idx),
>> + 0xffff & ~TCU_TCSR_RESERVED_BITS, 0);
>> +}
>> +
>> +static void __init ingenic_tcu_free_channel(struct
>> ingenic_tcu_channel *channel)
>> +{
>> + struct ingenic_tcu *tcu = to_ingenic_tcu(channel);
>> +
>> + clk_disable_unprepare(channel->clk);
>> + clk_put(channel->clk);
>> + clear_bit(channel->idx, &tcu->requested);
>> +}
>> +
>> +static const char * const ingenic_tcu_timer_names[] = {
>> + "TCU0", "TCU1", "TCU2", "TCU3", "TCU4", "TCU5", "TCU6", "TCU7",
>> +};
>> +
>> +static int __init ingenic_tcu_setup_cevt(struct device_node *np,
>> + struct ingenic_tcu *tcu, unsigned int idx)
>> +{
>> + struct ingenic_tcu_channel *channel = &tcu->channels[idx];
>> + struct ingenic_clock_event_device *jzcevt;
>> + unsigned long rate;
>> + int err, virq;
>> +
>> + err = ingenic_tcu_req_channel(channel);
>> + if (err)
>> + return err;
>> +
>> + err = ingenic_tcu_reset_channel(np, channel);
>> + if (err)
>> + goto err_out_free_channel;
>> +
>> + rate = clk_get_rate(channel->clk);
>> + if (!rate) {
>> + err = -EINVAL;
>> + goto err_out_free_channel;
>> + }
>> +
>> + jzcevt = kzalloc(sizeof(*jzcevt), GFP_KERNEL);
>> + if (!jzcevt) {
>> + err = -ENOMEM;
>> + goto err_out_free_channel;
>> + }
>> +
>> + virq = irq_of_parse_and_map(np, idx);
>> + if (!virq) {
>> + err = -EINVAL;
>> + goto err_out_kfree_jzcevt;
>> + }
>> +
>> + err = request_irq(virq, ingenic_tcu_cevt_cb, IRQF_TIMER,
>> + ingenic_tcu_timer_names[idx], &jzcevt->cevt);
>> + if (err)
>> + goto err_out_irq_dispose_mapping;
>> +
>> + jzcevt->channel = channel;
>> + snprintf(jzcevt->name, sizeof(jzcevt->name), "ingenic-tcu-chan%u",
>> + channel->idx);
>> +
>> + jzcevt->cevt.cpumask = cpumask_of(smp_processor_id());
>> + jzcevt->cevt.features = CLOCK_EVT_FEAT_ONESHOT;
>> + jzcevt->cevt.name = jzcevt->name;
>> + jzcevt->cevt.rating = 200;
>> + jzcevt->cevt.set_state_shutdown =
>> ingenic_tcu_cevt_set_state_shutdown;
>> + jzcevt->cevt.set_next_event = ingenic_tcu_cevt_set_next;
>> +
>> + clockevents_config_and_register(&jzcevt->cevt, rate, 10, (1 << 16) -
>> 1);
>> +
>> + return 0;
>> +
>> +err_out_irq_dispose_mapping:
>> + irq_dispose_mapping(virq);
>> +err_out_kfree_jzcevt:
>> + kfree(jzcevt);
>> +err_out_free_channel:
>> + ingenic_tcu_free_channel(channel);
>> + return err;
>> +}
>> +
>> +static int __init ingenic_tcu_init(struct device_node *np)
>> +{
>> + unsigned long available_channels = GENMASK(NUM_CHANNELS - 1, 0);
>> + struct device_node *node, *pwm_driver_node;
>> + struct ingenic_tcu *tcu;
>> + unsigned int i, channel;
>> + int err;
>> + u32 val;
>> +
>> + /* Parse the devicetree for clients of the TCU PWM driver;
>> + * every TCU channel not requested for PWM will be used as
>> + * a timer.
>> + */
>
>
>
>> + for_each_node_with_property(node, "pwms") {
>> + /* Get the PWM channel ID (field 1 of the "pwms" node) */
>> + err = of_property_read_u32_index(node, "pwms", 1, &val);
>> + if (!err && val >= NUM_CHANNELS)
>> + err = -EINVAL;
>> + if (err) {
>> + pr_err("timer-ingenic: Unable to parse PWM nodes!");
>> + break;
>> + }
>> +
>> + /* Get the PWM driver node (field 0 of the "pwms" node) */
>> + pwm_driver_node = of_parse_phandle(node, "pwms", 0);
>> + if (!pwm_driver_node) {
>> + pr_err("timer-ingenic: Unable to find PWM driver node");
>> + break;
>> + }
>> +
>> + /* Verify that the node we found is for the TCU PWM driver,
>> + * by checking that this driver and the PWM driver passed
>> + * as phandle share the same parent (the "ingenic,tcu"
>> + * compatible MFD/syscon node).
>> + */
>> + if (pwm_driver_node->parent != np->parent)
>> + continue;
>> +
>> + pr_info("timer-ingenic: Reserving channel %u for PWM", val);
>> + available_channels &= ~BIT(val);
>> + }
>> +
>> + tcu = kzalloc(sizeof(*tcu), GFP_KERNEL);
>> + if (!tcu)
>> + return -ENOMEM;
>> +
>> + tcu->map = syscon_node_to_regmap(np->parent);
>> + if (IS_ERR(tcu->map)) {
>> + err = PTR_ERR(tcu->map);
>> + kfree(tcu);
>> + return err;
>> + }
>> +
>> + for (i = 0; i < NUM_CHANNELS; i++)
>> + tcu->channels[i].idx = i;
>
> I'm pretty sure you can do better thaningenic_tcu_setup that :)
I didn't think this would be a problem. I guess I can try.
>> + for_each_set_bit(channel, &available_channels, NUM_CHANNELS) {
>> + err = _cevt(np, tcu, channel);
>> + if (err) {
>> + pr_warn("timer-ingenic: Unable to init TCU channel %u: %i",
>> + channel, err);
>> + continue;
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +/* We only probe via devicetree, no need for a platform driver */
>> +CLOCKSOURCE_OF_DECLARE(jz4740_tcu, "ingenic,jz4740-tcu",
>> ingenic_tcu_init);
>> +CLOCKSOURCE_OF_DECLARE(jz4770_tcu, "ingenic,jz4770-tcu",
>> ingenic_tcu_init);
>> +CLOCKSOURCE_OF_DECLARE(jz4780_tcu, "ingenic,jz4780-tcu",
>> ingenic_tcu_init);
>
> s/CLOCKSOURCE_OF_DECLARE/TIMER_OF_DECLARE/
Sure, OK.
Thanks!
-Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 0/8] Ingenic JZ47xx Timer/Counter Unit drivers
From: Daniel Lezcano @ 2018-03-28 15:10 UTC (permalink / raw)
To: Paul Cercueil
Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Lee Jones,
Ralf Baechle, Rob Herring, Jonathan Corbet, Mark Rutland,
James Hogan, Maarten ter Huurne, linux-clk, devicetree,
linux-kernel, linux-mips, linux-doc
In-Reply-To: <2fb3344b4034385ed89bcdf7da2347d4@crapouillou.net>
On 28/03/2018 17:01, Paul Cercueil wrote:
> Le 2018-03-18 23:13, Daniel Lezcano a écrit :
>> On 18/03/2018 00:28, Paul Cercueil wrote:
>>> Hi,
>>>
>>> This is the 4th version of my TCU patchset.
>>>
>>> The major change is a greatly improved documentation, both in-code
>>> and as separate text files, to describe how the hardware works and
>>> how the devicetree bindings should be used.
>>>
>>> There are also cosmetic changes in the irqchip driver, and the
>>> clocksource driver will now use as timers all TCU channels not
>>> requested by the TCU PWM driver.
>>
>> Hi Paul,
>>
>> I don't know why but you series appears in reply to [PATCH v3 2/9]. Not
>> sure if it is my mailer or how you are sending the patches but if it is
>> the latter can you in the future, when resending a new version, not use
>> the in-reply-to option. It will be easier to follow the versions.
>>
>> Thanks.
>>
>> -- Daniel
>
> Hi Daniel,
>
> I guess I did a mistake. I always reply to the first patch of the previous
> version of the patchset (is that correct?).
It depends, if you have a threaded view of emails, it is not easy to
review the patches when they are in several levels. Usually you can see
the patches is top posted without in-reply-to every version.
You can use in-reply-to to an email suggesting a change in order to give
context.
For the v4 series of these drivers, I'm lost :/
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 4/8] dt-bindings: Add doc for the Ingenic TCU drivers,
From: Paul Cercueil @ 2018-03-28 15:09 UTC (permalink / raw)
To: Marc Zyngier
Cc: Thomas Gleixner, Jason Cooper, Lee Jones, Daniel Lezcano,
Ralf Baechle, Rob Herring, Jonathan Corbet, Mark Rutland,
James Hogan, Maarten ter Huurne, linux-clk, devicetree,
linux-kernel, linux-mips, linux-doc
In-Reply-To: <b853fabf-4812-cefc-dd8b-f9ab596e1a36@arm.com>
Le 2018-03-20 09:52, Marc Zyngier a écrit :
> On 17/03/18 23:28, Paul Cercueil wrote:
>> Add documentation about how to properly use the Ingenic TCU
>> (Timer/Counter Unit) drivers from devicetree.
>>
>> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
>> ---
>> .../bindings/clock/ingenic,tcu-clocks.txt | 42
>> ++++++++++++++++
>> .../bindings/interrupt-controller/ingenic,tcu.txt | 39
>> +++++++++++++++
>> .../devicetree/bindings/mfd/ingenic,tcu.txt | 56
>> ++++++++++++++++++++++
>> .../devicetree/bindings/timer/ingenic,tcu.txt | 41
>> ++++++++++++++++
>> 4 files changed, 178 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
>> create mode 100644
>> Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
>> create mode 100644
>> Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
>> create mode 100644
>> Documentation/devicetree/bindings/timer/ingenic,tcu.txt
>>
>> v4: New patch in this series. Corresponds to V2 patches 3-4-5 with
>> added content.
>>
>> diff --git
>> a/Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
>> b/Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
>> new file mode 100644
>> index 000000000000..471d27078599
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
>> @@ -0,0 +1,42 @@
>> +Ingenic SoC TCU binding
>> +
>> +The TCU is the Timer/Counter Unit present in all Ingenic SoCs. It
>> features 8
>> +channels, each one having its own clock, that can be started and
>> stopped,
>> +reparented, and reclocked.
>> +
>> +Required properties:
>> +- compatible : One of:
>> + * ingenic,jz4740-tcu-clocks,
>> + * ingenic,jz4770-tcu-clocks,
>> + * ingenic,jz4780-tcu-clocks.
>> +- clocks : List of phandle & clock specifiers for clocks external to
>> the TCU.
>> + The "pclk", "rtc" and "ext" clocks should be provided.
>> +- clock-names : List of name strings for the external clocks.
>> +- #clock-cells: Should be 1.
>> + Clock consumers specify this argument to identify a clock. The
>> valid values
>> + may be found in <dt-bindings/clock/ingenic,tcu.h>.
>> +
>> +Example:
>> +
>> +/ {
>> + tcu: mfd@10002000 {
>> + compatible = "ingenic,tcu", "simple-mfd", "syscon";
>> + reg = <0x10002000 0x1000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x0 0x10002000 0x1000>;
>> +
>> + tcu_clk: clocks@10 {
>> + compatible = "ingenic,jz4740-tcu-clocks";
>> + reg = <0x10 0xff0>;
>> +
>> + clocks = <&ext>, <&rtc>, <&pclk>;
>> + clock-names = "ext", "rtc", "pclk";
>> +
>> + #clock-cells = <1>;
>> + };
>> + };
>> +};
>> +
>> +For information about the top-level "ingenic,tcu" compatible node and
>> other
>> +children nodes, see
>> Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
>> diff --git
>> a/Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
>> b/Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
>> new file mode 100644
>> index 000000000000..7f3af2da77cd
>> --- /dev/null
>> +++
>> b/Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
>> @@ -0,0 +1,39 @@
>> +Ingenic SoCs Timer/Counter Unit Interrupt Controller
>> +
>> +Required properties:
>> +
>> +- compatible : should be "ingenic,<socname>-tcu-intc". Valid strings
>> are:
>> + * ingenic,jz4740-tcu-intc
>> + * ingenic,jz4770-tcu-intc
>> + * ingenic,jz4780-tcu-intc
>> +- interrupt-controller : Identifies the node as an interrupt
>> controller
>> +- #interrupt-cells : Specifies the number of cells needed to encode
>> an
>> + interrupt source. The value shall be 1.
>> +- interrupt-parent : phandle of the interrupt controller.
>> +- interrupts : Specifies the interrupt the controller is connected
>> to.
>> +
>> +Example:
>> +
>> +/ {
>> + tcu: mfd@10002000 {
>> + compatible = "ingenic,tcu", "simple-mfd", "syscon";
>> + reg = <0x10002000 0x1000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x0 0x10002000 0x1000>;
>> +
>> + tcu_irq: interrupt-controller@20 {
>> + compatible = "ingenic,jz4740-tcu-intc";
>> + reg = <0x20 0x20>;
>> +
>> + interrupt-controller;
>> + #interrupt-cells = <1>;
>> +
>> + interrupt-parent = <&intc>;
>> + interrupts = <15>;
>> + };
>> + };
>> +};
>> +
>> +For information about the top-level "ingenic,tcu" compatible node and
>> other
>> +children nodes, see
>> Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
>> diff --git a/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
>> b/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
>> new file mode 100644
>> index 000000000000..5742c3f21550
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
>> @@ -0,0 +1,56 @@
>> +Ingenic JZ47xx SoCs Timer/Counter Unit devicetree bindings
>> +----------------------------------------------------------
>> +
>> +For a description of the TCU hardware and drivers, have a look at
>> +Documentation/mips/ingenic-tcu.txt.
>> +
>> +The TCU is implemented as a parent node, whose role is to create the
>> +regmap, and child nodes for the various drivers listed in the
>> aforementioned
>> +document.
>
> You're describing the Linux driver here. Please stick to a description
> of the HW.
There's already a whole file that describes the hardware. I just wanted
to mention
that there should be child nodes, but I can rephrase that.
>> +
>> +Required properties:
>> +
>> +- compatible: must be "ingenic,tcu", "simple-mfd", "syscon";
>
> Without any provision for an SoC version? Seems bold...
Well, we don't use the "ingenic,tcu" compatible string, the parent node
is just
here to create the regmap (in this version of the patchset, it will
probably change
later).
>> +- reg: Should be the offset/length value corresponding to the TCU
>> registers
>> +- #address-cells: Should be <1>;
>> +- #size-cells: Should be <1>;
>> +- ranges: Should be one range for the full TCU registers area
>> +
>> +Accepted children nodes:
>> +-
>> Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
>> +- Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
>> +- Documentation/devicetree/bindings/timer/ingenic,tcu.txt
>
> It is slightly confusing that you have 3 files named ingenic,tcu.txt.
> How about ingenic,tcu-intc.txt and ingenic,tcu-timer.txt (amending the
> binding for the timer)?
Right. I'll change that.
>> +
>> +
>> +Example:
>> +
>> +/ {
>> + tcu: mfd@10002000 {
>> + compatible = "ingenic,tcu", "simple-mfd", "syscon";
>> + reg = <0x10002000 0x1000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x0 0x10002000 0x1000>;
>> +
>> + tcu_irq: interrupt-controller@20 {
>> + compatible = "ingenic,jz4740-tcu-intc";
>> + reg = <0x20 0x20>;
>> + ...
>> + };
>> +
>> + tcu_clk: clocks@10 {
>> + compatible = "ingenic,jz4740-tcu-clocks";
>> + reg = <0x10 0xff0>;
>> + ...
>> + };
>> +
>> + tcu_timer: timer@10 {
>> + compatible = "ingenic,jz4740-tcu";
>> + reg = <0x10 0xff0>;
>> + ...
>> + };
>> + };
>> +};
>> +
>> +For more information about the children node, refer to the documents
>> listed
>> +above in the "Accepted children nodes" section.
>> diff --git a/Documentation/devicetree/bindings/timer/ingenic,tcu.txt
>> b/Documentation/devicetree/bindings/timer/ingenic,tcu.txt
>> new file mode 100644
>> index 000000000000..f910b7e96783
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/timer/ingenic,tcu.txt
>> @@ -0,0 +1,41 @@
>> +Ingenic JZ47xx SoCs Timer/Counter Unit driver
>> +---------------------------------------------
>> +
>> +Required properties:
>> +
>> +- compatible : should be "ingenic,<socname>-tcu". Valid strings are:
>> + * ingenic,jz4740-tcu
>> + * ingenic,jz4770-tcu
>> + * ingenic,jz4780-tcu
>> +- interrupt-parent : phandle of the TCU interrupt controller.
>> +- interrupts : Specifies the interrupts the controller is connected
>> to.
>> +- clocks : List of phandle & clock specifiers for the TCU clocks.
>> +- clock-names : List of name strings for the TCU clocks.
>> +
>> +Example:
>> +
>> +/ {
>> + tcu: mfd@10002000 {
>> + compatible = "ingenic,tcu", "simple-mfd", "syscon";
>> + reg = <0x10002000 0x1000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x0 0x10002000 0x1000>;
>> +
>> + tcu_timer: timer@10 {
>> + compatible = "ingenic,jz4740-tcu";
>> + reg = <0x10 0xff0>;
>> +
>> + clocks = <&tcu_clk 0>, <&tcu_clk 1>, <&tcu_clk 2>, <&tcu_clk 3>,
>> + <&tcu_clk 4>, <&tcu_clk 5>, <&tcu_clk 6>, <&tcu_clk 7>;
>> + clock-names = "timer0", "timer1", "timer2", "timer3",
>> + "timer4", "timer5", "timer6", "timer7";
>> +
>> + interrupt-parent = <&tcu_irq>;
>> + interrupts = <0 1 2 3 4 5 6 7>;
>> + };
>> + };
>> +};
>> +
>> +For information about the top-level "ingenic,tcu" compatible node and
>> other
>> +children nodes, see
>> Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
>>
>
> Thanks,
>
> M.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 2/8] dt-bindings: ingenic: Add DT bindings for TCU clocks,
From: Paul Cercueil @ 2018-03-28 15:04 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Lee Jones,
Daniel Lezcano, Ralf Baechle, Rob Herring, Jonathan Corbet,
Mark Rutland, James Hogan, Maarten ter Huurne, linux-clk,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML,
Linux-MIPS, linux-doc, mathieu.malaterre
In-Reply-To: <CA+7wUsyAkW+Bgmp6MuWTce1jMG-ug1b-UqFVen_vVeKFiW5Fww@mail.gmail.com>
Le 2018-03-20 08:15, Mathieu Malaterre a écrit :
> Hi Paul,
>
> Two things:
>
> On Sun, Mar 18, 2018 at 12:28 AM, Paul Cercueil <paul@crapouillou.net>
> wrote:
>> This header provides clock numbers for the ingenic,tcu
>> DT binding.
>
> I have tested the whole series on my Creator CI20 with success, using:
>
> + tcu@10002000 {
> + compatible = "ingenic,jz4780-tcu";
> + reg = <0x10002000 0x140>;
> +
> + interrupt-parent = <&intc>;
> + interrupts = <27 26 25>;
> + };
>
>
> So:
>
> Tested-by: Mathieu Malaterre <malat@debian.org>
Great! Is that for the whole patchset or just this one patch?
>> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
>> Reviewed-by: Rob Herring <robh@kernel.org>
>> ---
>> include/dt-bindings/clock/ingenic,tcu.h | 23 +++++++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>> create mode 100644 include/dt-bindings/clock/ingenic,tcu.h
>>
>> v2: Use SPDX identifier for the license
>> v3: No change
>> v4: No change
>>
>> diff --git a/include/dt-bindings/clock/ingenic,tcu.h
>> b/include/dt-bindings/clock/ingenic,tcu.h
>> new file mode 100644
>> index 000000000000..179815d7b3bb
>> --- /dev/null
>> +++ b/include/dt-bindings/clock/ingenic,tcu.h
>> @@ -0,0 +1,23 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * This header provides clock numbers for the ingenic,tcu DT binding.
>> + */
>> +
>> +#ifndef __DT_BINDINGS_CLOCK_INGENIC_TCU_H__
>> +#define __DT_BINDINGS_CLOCK_INGENIC_TCU_H__
>> +
>> +#define JZ4740_CLK_TIMER0 0
>> +#define JZ4740_CLK_TIMER1 1
>> +#define JZ4740_CLK_TIMER2 2
>> +#define JZ4740_CLK_TIMER3 3
>> +#define JZ4740_CLK_TIMER4 4
>> +#define JZ4740_CLK_TIMER5 5
>> +#define JZ4740_CLK_TIMER6 6
>> +#define JZ4740_CLK_TIMER7 7
>> +#define JZ4740_CLK_WDT 8
>> +#define JZ4740_CLK_LAST JZ4740_CLK_WDT
>> +
>> +#define JZ4770_CLK_OST 9
>> +#define JZ4770_CLK_LAST JZ4770_CLK_OST
>> +
>
> When working on JZ4780 support, I always struggle to read those kind
> of #define. Since this is a new patch would you mind changing
> s/JZ4740/JZ47XX/ in your header ?
Well the idea was that these defines are for JZ4740 and newer.
But that means all Ingenic SoCs, so I guess I can change it.
> Thanks for your work on JZ !
Sure, thank you for testing!
>> +#endif /* __DT_BINDINGS_CLOCK_INGENIC_TCU_H__ */
>> --
>> 2.11.0
>>
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 0/8] Ingenic JZ47xx Timer/Counter Unit drivers,
From: Paul Cercueil @ 2018-03-28 15:01 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Lee Jones,
Ralf Baechle, Rob Herring, Jonathan Corbet, Mark Rutland,
James Hogan, Maarten ter Huurne, linux-clk, devicetree,
linux-kernel, linux-mips, linux-doc
In-Reply-To: <aeb57b92-6932-9774-dc50-7563d30846bf@linaro.org>
Le 2018-03-18 23:13, Daniel Lezcano a écrit :
> On 18/03/2018 00:28, Paul Cercueil wrote:
>> Hi,
>>
>> This is the 4th version of my TCU patchset.
>>
>> The major change is a greatly improved documentation, both in-code
>> and as separate text files, to describe how the hardware works and
>> how the devicetree bindings should be used.
>>
>> There are also cosmetic changes in the irqchip driver, and the
>> clocksource driver will now use as timers all TCU channels not
>> requested by the TCU PWM driver.
>
> Hi Paul,
>
> I don't know why but you series appears in reply to [PATCH v3 2/9]. Not
> sure if it is my mailer or how you are sending the patches but if it is
> the latter can you in the future, when resending a new version, not use
> the in-reply-to option. It will be easier to follow the versions.
>
> Thanks.
>
> -- Daniel
Hi Daniel,
I guess I did a mistake. I always reply to the first patch of the
previous
version of the patchset (is that correct?).
Thanks,
-Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] Documentation/thermal: Check links and convert to https
From: Sanjeev Gupta @ 2018-03-28 14:59 UTC (permalink / raw)
To: corbet, linux-pm; +Cc: linux-doc, linux-kernel, viresh.kumar
All links working.
Signed-off-by: Sanjeev Gupta <ghane0@gmail.com>
---
Documentation/thermal/cpu-cooling-api.txt | 2 +-
Documentation/thermal/nouveau_thermal | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt
index 7df567eaea1a..32917d178c51 100644
--- a/Documentation/thermal/cpu-cooling-api.txt
+++ b/Documentation/thermal/cpu-cooling-api.txt
@@ -5,7 +5,7 @@ Written by Amit Daniel Kachhap <amit.kachhap@linaro.org>
Updated: 6 Jan 2015
-Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com)
+Copyright (c) 2012 Samsung Electronics Co., Ltd (https://www.samsung.com)
0. Introduction
diff --git a/Documentation/thermal/nouveau_thermal b/Documentation/thermal/nouveau_thermal
index 6e17a11efcb0..502b0b95c2e2 100644
--- a/Documentation/thermal/nouveau_thermal
+++ b/Documentation/thermal/nouveau_thermal
@@ -79,4 +79,4 @@ Thermal management on Nouveau is new and may not work on all cards. If you have
inquiries, please ping mupuf on IRC (#nouveau, freenode).
Bug reports should be filled on Freedesktop's bug tracker. Please follow
-http://nouveau.freedesktop.org/wiki/Bugs
+https://nouveau.freedesktop.org/wiki/Bugs
--
2.15.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v4 3/8] doc: Add doc for the Ingenic TCU hardware,
From: Paul Cercueil @ 2018-03-28 14:59 UTC (permalink / raw)
To: Randy Dunlap
Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Lee Jones,
Daniel Lezcano, Ralf Baechle, Rob Herring, Jonathan Corbet,
Mark Rutland, James Hogan, Maarten ter Huurne, linux-clk,
devicetree, linux-kernel, linux-mips, linux-doc
In-Reply-To: <1e5b82ca-5ac3-6e98-d40b-67916008b485@infradead.org>
Le 2018-03-18 00:52, Randy Dunlap a écrit :
> On 03/17/2018 04:28 PM, Paul Cercueil wrote:
>> Add a documentation file about the Timer/Counter Unit (TCU)
>> present in the Ingenic JZ47xx SoCs.
>>
>> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
>> ---
>> Documentation/mips/00-INDEX | 3 +++
>> Documentation/mips/ingenic-tcu.txt | 50
>> ++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 53 insertions(+)
>> create mode 100644 Documentation/mips/ingenic-tcu.txt
>>
>> v4: New patch in this series
>
>> diff --git a/Documentation/mips/ingenic-tcu.txt
>> b/Documentation/mips/ingenic-tcu.txt
>> new file mode 100644
>> index 000000000000..2508e5793da8
>> --- /dev/null
>> +++ b/Documentation/mips/ingenic-tcu.txt
>> @@ -0,0 +1,50 @@
>> +Ingenic JZ47xx SoCs Timer/Counter Unit hardware
>> +-----------------------------------------------
>> +
>> +The Timer/Counter Unit (TCU) in Ingenic JZ47xx SoCs is a
>> multi-function
>> +hardware block. It features eight channels, that can be used as
>> counters,
>
> drop comma ............. ^
Ok.
>> +timers, or PWM.
>> +
>> +- JZ4770 introduced a separate channel, called Operating System Timer
>> (OST).
>> + It is a 64-bit programmable timer.
>> +
>> +- Each one of the eight channels has its own clock, which can be
>> reparented
>> + to three different clocks (pclk, ext, rtc), gated, and reclocked,
>> through
>> + their TCSR register.
>> + * The watchdog and OST hardware blocks also feature a TCSR register
>> with
>> + the same format in their register space.
>> + * The TCU registers used to gate/ungate can also gate/ungate the
>> watchdog
>> + and OST clocks.
>> +
>> +- On SoCs >= JZ4770, there are two different modes:
>> + * Channels 0, 3-7 operate in TCU1 mode: they cannot work in sleep
>> mode,
>> + but are easier to operate.
>> + * Channels 1-2 operate in TCU2 mode: they can work in sleep mode,
>> but
>> + the operation is a bit more complicated than with TCU1 channels.
>> +
>> +- Each channel can generate an interrupt. Some channels share an
>> interrupt
>> + line, some don't, and this changes between SoC versions:
>> + * on JZ4740, timer 0 and timer 1 have their own interrupt line;
>> others share
>> + one interrupt line.
>> + * on JZ4770 and JZ4780, timer 5 has its own interrupt; timers 0-4
>> and 6-7 all
>> + use one interrupt line; the OST uses the last interrupt.
>
> "The OST uses the last interrupt." is not clear to someone who doesn't
> know
> about this hardware. (I can read it several ways.)
>
> Does it mean that the 4770 and 4780 have 3 interrupt lines used like
> so?
>
> - timer 5 uses one interrupt line
> - timers 0-4 and 6-7 use a second interrupt line
> - the OST uses a third interrupt line
Correct. I'll make it more obvious.
Thanks,
-Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] Documentation/wimax: Point dead link to working copy
From: Sanjeev Gupta @ 2018-03-28 14:47 UTC (permalink / raw)
To: corbet, linux-wimax; +Cc: linux-doc
The linuxwimax.org domain, registered by the Linux Foundation,
no longer has any DNS entries. Locate a copy on archive.org and
update the documentation.
Signed-off-by: Sanjeev Gupta <ghane0@gmail.com>
---
Documentation/wimax/README.i2400m | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/wimax/README.i2400m b/Documentation/wimax/README.i2400m
index 7dffd8919cb0..d11502d17818 100644
--- a/Documentation/wimax/README.i2400m
+++ b/Documentation/wimax/README.i2400m
@@ -61,8 +61,9 @@ $ make KDIR=/path/to/kernel/dev/tree
3. Installing the firmware
- The firmware can be obtained from http://linuxwimax.org or might have
- been supplied with your hardware.
+ The firmware can be obtained from
+ https://web.archive.org/web/20101224002849/http://linuxwimax.org/
+ or might have been supplied with your hardware.
It has to be installed in the target system:
*
--
2.15.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] docs/memory-barriers.txt: Fix broken DMA vs MMIO ordering example
From: Sinan Kaya @ 2018-03-28 13:02 UTC (permalink / raw)
To: paulmck, Will Deacon
Cc: linux-kernel@vger.kernel.org, linux-doc, Benjamin Herrenschmidt,
Arnd Bergmann, Jason Gunthorpe, Peter Zijlstra, Ingo Molnar,
Jonathan Corbet, linux-ia64
In-Reply-To: <20180327150252.GN3675@linux.vnet.ibm.com>
+linux-ia64
On 3/27/2018 11:02 AM, Paul E. McKenney wrote:
> On Tue, Mar 27, 2018 at 02:11:27PM +0100, Will Deacon wrote:
>> The section of memory-barriers.txt that describes the dma_Xmb() barriers
>> has an incorrect example claiming that a wmb() is required after writing
>> to coherent memory in order for those writes to be visible to a device
>> before a subsequent MMIO access using writel() can reach the device.
>>
>> In fact, this ordering guarantee is provided (at significant cost on some
>> architectures such as arm and power) by writel, so the wmb() is not
>> necessary. writel_relaxed exists for cases where this ordering is not
>> required.
>>
>> Fix the example and update the text to make this clearer.
>>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Cc: Jason Gunthorpe <jgg@ziepe.ca>
>> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
>> Cc: Peter Zijlstra <peterz@infradead.org>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: Jonathan Corbet <corbet@lwn.net>
>> Reported-by: Sinan Kaya <okaya@codeaurora.org>
>> Signed-off-by: Will Deacon <will.deacon@arm.com>
>
> Good catch, queued on my lkmm branch, thank you!
>
> Thanx, Paul
>
Does IA64 follow this requirement? If not, is implementation planned?
"no wmb() before writel()"
Linus asked us to get rid of wmb() in front of writel() for UC memory.
Just checking that we are not breaking anything for IA64.
>> ---
>> Documentation/memory-barriers.txt | 17 +++++++++--------
>> 1 file changed, 9 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
>> index a863009849a3..3247547d1c36 100644
>> --- a/Documentation/memory-barriers.txt
>> +++ b/Documentation/memory-barriers.txt
>> @@ -1909,9 +1909,6 @@ There are some more advanced barrier functions:
>> /* assign ownership */
>> desc->status = DEVICE_OWN;
>>
>> - /* force memory to sync before notifying device via MMIO */
>> - wmb();
>> -
>> /* notify device of new descriptors */
>> writel(DESC_NOTIFY, doorbell);
>> }
>> @@ -1919,11 +1916,15 @@ There are some more advanced barrier functions:
>> The dma_rmb() allows us guarantee the device has released ownership
>> before we read the data from the descriptor, and the dma_wmb() allows
>> us to guarantee the data is written to the descriptor before the device
>> - can see it now has ownership. The wmb() is needed to guarantee that the
>> - cache coherent memory writes have completed before attempting a write to
>> - the cache incoherent MMIO region.
>> -
>> - See Documentation/DMA-API.txt for more information on consistent memory.
>> + can see it now has ownership. Note that, when using writel(), a prior
>> + wmb() is not needed to guarantee that the cache coherent memory writes
>> + have completed before writing to the MMIO region. The cheaper
>> + writel_relaxed() does not provide this guarantee and must not be used
>> + here.
>> +
>> + See the subsection "Kernel I/O barrier effects" for more information on
>> + relaxed I/O accessors and the Documentation/DMA-API.txt file for more
>> + information on consistent memory.
>>
>>
>> MMIO WRITE BARRIER
>> --
>> 2.1.4
>>
>
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [Question] Documentation/features: More automation/scripting help?
From: Andrea Parri @ 2018-03-28 12:22 UTC (permalink / raw)
To: Jonathan Corbet, Ingo Molnar, Andy Whitcroft, Joe Perches,
Linus Torvalds
Cc: linux-doc, linux-kernel, linux-arch
Hi all,
The directory (not yet three years old although, I freely admit, I've
only recently become aware of it) provides arch. support matrices for
more than 40 generic kernel features that need per-arch. support:
This is a superb project! ;-) and not a simple one given that, to be
effective, this requires the prompt collaboration between (the intere-
sted) features maintainers/developers, every architecture maintainers,
and documentation maintainers.
There currently appear to be some mismatches between such doc and the
the actual state of the code (e.g., missing architecture, feature not
existing anymore, status flags out-of-date). Realized this, I started
to patch the doc, but this process became soon tedious (consider also
that I barely know what some of these features are about...).
Hence this post. I am wondering if it would make sense to script some
of these matrices. So, rather than (or together with) using the cur-
rently hard-coded matrices, try to (automatically) generate them from
the sources/configs. Consider the sketch below (sorry for the raw sh).
diff --git a/Documentation/features/list-arch.sh b/Documentation/features/list-arch.sh
index c16b5b5956889..cdec0c1db9db2 100755
--- a/Documentation/features/list-arch.sh
+++ b/Documentation/features/list-arch.sh
@@ -18,7 +18,13 @@ for F in */*/arch-support.txt; do
C=$(grep -h "^# Kconfig:" $F | cut -c25-)
D=$(grep -h "^# description:" $F | cut -c25-)
S=$(grep -hw $ARCH $F | cut -d\| -f3)
+ myS=$(grep -h $C ../../arch/$ARCH/Kconfig)
+ if [ -z "$myS" ]; then
+ myS=" -- "
+ else
+ myS=" ok "
+ fi
- printf "%10s/%-22s:%s| %35s # %s\n" "$SUBSYS" "$N" "$S" "$C" "$D"
+ printf "%10s/%-22s:%s VS. %s| %35s # %s\n" "$SUBSYS" "$N" "$S" "$myS" "$C" "$D"
done
With this diff.,
andrea@andrea:~$ ./Documentation/features/list-arch.sh riscv > /tmp/riscv.txt
grep: asm/rwsem.h: No such file or directory
andrea@andrea:~$ cat /tmp/riscv.txt
#
# Kernel feature support matrix of the 'riscv' architecture:
#
core/ BPF-JIT : VS. -- | HAVE_BPF_JIT # arch supports BPF JIT optimizations
core/ generic-idle-thread : VS. ok | GENERIC_SMP_IDLE_THREAD # arch makes use of the generic SMP idle thread facility
core/ jump-labels : VS. -- | HAVE_ARCH_JUMP_LABEL # arch supports live patched, high efficiency branches
core/ tracehook : VS. ok | HAVE_ARCH_TRACEHOOK # arch supports tracehook (ptrace) register handling APIs
debug/ gcov-profile-all : VS. -- | ARCH_HAS_GCOV_PROFILE_ALL # arch supports whole-kernel GCOV code coverage profiling
debug/ KASAN : VS. -- | HAVE_ARCH_KASAN # arch supports the KASAN runtime memory checker
debug/ kgdb : VS. -- | HAVE_ARCH_KGDB # arch supports the kGDB kernel debugger
debug/ kprobes : VS. ok | HAVE_KPROBES # arch supports live patched kernel probe
debug/ kprobes-on-ftrace : VS. -- | HAVE_KPROBES_ON_FTRACE # arch supports combined kprobes and ftrace live patching
debug/ kretprobes : VS. -- | HAVE_KRETPROBES # arch supports kernel function-return probes
debug/ optprobes : VS. -- | HAVE_OPTPROBES # arch supports live patched optprobes
debug/ stackprotector : VS. -- | HAVE_CC_STACKPROTECTOR # arch supports compiler driven stack overflow protection
debug/ uprobes : VS. -- | ARCH_SUPPORTS_UPROBES # arch supports live patched user probes
debug/ user-ret-profiler : VS. -- | HAVE_USER_RETURN_NOTIFIER # arch supports user-space return from system call profiler
io/ dma-api-debug : VS. ok | HAVE_DMA_API_DEBUG # arch supports DMA debug facilities
io/ dma-contiguous : VS. ok | HAVE_DMA_CONTIGUOUS # arch supports the DMA CMA (continuous memory allocator)
io/ sg-chain : VS. -- | ARCH_HAS_SG_CHAIN # arch supports chained scatter-gather lists
lib/ strncasecmp : VS. -- | __HAVE_ARCH_STRNCASECMP # arch provides an optimized strncasecmp() function
locking/ cmpxchg-local : VS. -- | HAVE_CMPXCHG_LOCAL # arch supports the this_cpu_cmpxchg() API
locking/ lockdep : VS. -- | LOCKDEP_SUPPORT # arch supports the runtime locking correctness debug facility
locking/ queued-rwlocks : VS. -- | ARCH_USE_QUEUED_RWLOCKS # arch supports queued rwlocks
locking/ queued-spinlocks : VS. -- | ARCH_USE_QUEUED_SPINLOCKS # arch supports queued spinlocks
locking/ rwsem-optimized : VS. -- | Optimized asm/rwsem.h # arch provides optimized rwsem APIs
perf/ kprobes-event : VS. -- | HAVE_REGS_AND_STACK_ACCESS_API # arch supports kprobes with perf events
perf/ perf-regs : VS. -- | HAVE_PERF_REGS # arch supports perf events register access
perf/ perf-stackdump : VS. -- | HAVE_PERF_USER_STACK_DUMP # arch supports perf events stack dumps
sched/ membarrier-sync-core : VS. -- | ARCH_HAS_MEMBARRIER_SYNC_CORE # arch supports core serializing membarrier
sched/ numa-balancing : VS. -- | ARCH_SUPPORTS_NUMA_BALANCING # arch supports NUMA balancing
seccomp/ seccomp-filter : VS. -- | HAVE_ARCH_SECCOMP_FILTER # arch supports seccomp filters
time/ arch-tick-broadcast : VS. -- | ARCH_HAS_TICK_BROADCAST # arch provides tick_broadcast()
time/ clockevents : VS. ok | GENERIC_CLOCKEVENTS # arch support generic clock events
time/ context-tracking : VS. -- | HAVE_CONTEXT_TRACKING # arch supports context tracking for NO_HZ_FULL
time/ irq-time-acct : VS. -- | HAVE_IRQ_TIME_ACCOUNTING # arch supports precise IRQ time accounting
time/ modern-timekeeping : VS. -- | !ARCH_USES_GETTIMEOFFSET # arch does not use arch_gettimeoffset() anymore
time/ virt-cpuacct : VS. -- | HAVE_VIRT_CPU_ACCOUNTING # arch supports precise virtual CPU time accounting
vm/ ELF-ASLR : VS. -- | ARCH_HAS_ELF_RANDOMIZE # arch randomizes the stack, heap and binary images of ELF binaries
vm/ huge-vmap : VS. -- | HAVE_ARCH_HUGE_VMAP # arch supports the ioremap_pud_enabled() and ioremap_pmd_enabled() VM APIs
vm/ ioremap_prot : VS. -- | HAVE_IOREMAP_PROT # arch has ioremap_prot()
vm/ numa-memblock : VS. ok | HAVE_MEMBLOCK_NODE_MAP # arch supports NUMA aware memblocks
vm/ PG_uncached : VS. -- | ARCH_USES_PG_UNCACHED # arch supports the PG_uncached page flag
vm/ pte_special : VS. -- | __HAVE_ARCH_PTE_SPECIAL # arch supports the pte_special()/pte_mkspecial() VM APIs
vm/ THP : VS. -- | HAVE_ARCH_TRANSPARENT_HUGEPAGE # arch supports transparent hugepages
vm/ batch-unmap-tlb-flush: VS. -- | ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH # arch supports deferral of TLB flush until multiple pages are unmapped
Suggesting that riscv is not included within the hard-coded matrices.
This also shows a first limitation of the proposed approach, i.e., it
doesn't parse "Optimized asm/rwsem.h" (wants "true" configs). It also
won't find "__HAVE_ARCH_PTE_SPECIAL" (reads Kconfig files) but things
like "!ARCH_USES_GETTIMEOFFSET" could still be handled...
We could try switching to another architectures: none of these should
result in "core/ BPF-JIT" set: the "HAVE_BPF_JIT" config was splitted
into cBPF and eBPF variants more recently. The comparison of the hard
coded status flags with the new/generated flags should also highlight
out-of-date values.
Alternative/Additional help could probably be provided by checkpatch,
say, warn when a patch touches/adds to Kconfig without updating such
documentation...
Thoughts?
Andrea
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v3 05/11] dt-bindings: i3c: Document core bindings
From: Boris Brezillon @ 2018-03-28 8:19 UTC (permalink / raw)
To: Rob Herring
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, devicetree, linux-kernel,
Vitor Soares, Geert Uytterhoeven, Linus Walleij, Xiang Lin,
linux-gpio, Boris Brezillon
In-Reply-To: <20180326071946.dtrhhxx3iwwymk73@rob-hp-laptop>
Hi Rob,
On Mon, 26 Mar 2018 17:24:58 -0500
Rob Herring <robh@kernel.org> wrote:
> > +
> > +I3C devices
> > +===========
> > +
> > +All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
> > +are thus discoverable. So, by default, I3C devices do not have to be described
> > +in the device tree.
> > +This being said, one might want to attach extra resources to these devices,
> > +and those resources may have to be described in the device tree, which in turn
> > +means we have to describe I3C devices.
> > +
> > +Another use case for describing an I3C device in the device tree is when this
> > +I3C device has a static address and we want to assign it a specific dynamic
> > +address before the DAA takes place (so that other devices on the bus can't
>
> static is I2C address and dynamic is an I3C address. That could be
> clearer throughout.
I'll clarify that.
>
> > +take this dynamic address).
> > +
> > +The I3C device should be names <device-type>@<static-address>,<i3c-pid>,
>
> s/static-address/static-i2c-address/
Okay.
>
> > +where device-type is describing the type of device connected on the bus
> > +(gpio-controller, sensor, ...).
> > +
> > +Required properties
> > +-------------------
> > +- reg: contains 3 cells
> > + + first cell : encodes the I2C address. Should be 0 if the device does not
> > + have one (0 is not a valid I3C address).
>
> Change here to "encodes the static I2C address".
>
> 0 is not a valid I2C address?
According to [1] it is reserved, and it's reserved in the I3C spec
anyway (see "Table 9 I3C Slave Address Restrictions" in the I3C spec).
>
> > +
> > + + second and third cells: should encode the ProvisionalID. The second cell
> > + contains the manufacturer ID left-shifted by 1.
> > + The third cell contains ORing of the part ID
> > + left-shifted by 16, the instance ID left-shifted
> > + by 12 and the extra information. This encoding is
> > + following the PID definition provided by the I3C
> > + specification.
One extra question for you: should I refer to the I3C_DEV(),
I3C_DEV_WITH_STATIC_ADDR() and I2C_DEV() macros in the bindings doc?
And if I do, should I use them my example?
Thanks,
Boris
> > +
> > +Optional properties
> > +-------------------
> > +- assigned-address: dynamic address to be assigned to this device. This
> > + property is only valid if the I3C device has a static
> > + address (first cell of the reg property != 0).
> > +
> > +
> > +Example:
> > +
> > + i3c-master@d040000 {
> > + compatible = "cdns,i3c-master";
> > + clocks = <&coreclock>, <&i3csysclock>;
> > + clock-names = "pclk", "sysclk";
> > + interrupts = <3 0>;
> > + reg = <0x0d040000 0x1000>;
> > + #address-cells = <3>;
> > + #size-cells = <0>;
> > +
> > + status = "okay";
> > + i2c-scl-frequency = <100000>;
> > +
> > + /* I2C device. */
> > + nunchuk: nunchuk@52 {
> > + compatible = "nintendo,nunchuk";
> > + reg = <0x52 0x80000010 0x0>;
> > + };
> > +
> > + /* I3C device with a static address. */
> > + thermal_sensor: sensor@68,39200144004 {
> > + reg = <0x68 0x392 0x144004>;
> > + assigned-address = <0xa>;
> > + };
> > +
> > + /*
> > + * I3C device without a static address but requiring resources
> > + * described in the DT.
> > + */
> > + sensor@0,39200154004 {
> > + reg = <0x0 0x392 0x154004>;
> > + clocks = <&clock_provider 0>;
> > + };
> > + };
> > +
> > --
> > 2.14.1
> >
[1]http://www.i2c-bus.org/addressing
--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 2/2] cpuset: Add cpuset.sched_load_balance to v2
From: Mike Galbraith @ 2018-03-28 6:57 UTC (permalink / raw)
To: Waiman Long, Tejun Heo
Cc: Juri Lelli, Li Zefan, Johannes Weiner, Peter Zijlstra,
Ingo Molnar, cgroups, linux-kernel, linux-doc, kernel-team, pjt,
luto, torvalds, Roman Gushchin
In-Reply-To: <e20484c9-e901-9737-d856-783a6eba1604@redhat.com>
On Tue, 2018-03-27 at 10:23 -0400, Waiman Long wrote:
> On 03/27/2018 10:02 AM, Tejun Heo wrote:
> > Hello,
> >
> > On Mon, Mar 26, 2018 at 04:28:49PM -0400, Waiman Long wrote:
> >> Maybe we can have a different root level flag, say,
> >> sched_partition_domain that is equivalent to !sched_load_balnace.
> >> However, I am still not sure if we should enforce that no task should be
> >> in the root cgroup when the flag is set.
> >>
> >> Tejun and Peter, what are your thoughts on this?
> > I haven't looked into the other issues too much but we for sure cannot
> > empty the root cgroup.
> >
> > Thanks.
> >
> Now, I have a different idea. How about we add a special root-only knob,
> say, "cpuset.cpus.isolated" that contains the list of CPUs that are
> still owned by root, but not participated in load balancing. All the
> tasks in the root are load-balanced among the remaining CPUs.
>
> A child can then be created that hold some or all the CPUs in the
> isolated set. It will then have a separate root domain if load balancing
> is on, or an isolated cpuset if load balancing is off.
>
> Will that idea work?
Hrm. Sounds very much like the typical v1 setup today..
root
/\
peons vips
...with v2 root effectively shrinking to become the v1 "peons" set
*rd/sd/sd_llc wise only* when you poke /cpuset.cpus.isolated, but still
actually spanning all CPUs. True?
If so, a user would also still have to create a real "peons" subset as
in v1 and migrate everything not nailed to the floor into it for
containment, else any task can be placed or place itself anywhere in
the box, or merely wake to find itself sitting on it's previous, but
now vip turf CPU.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC PATCH v2 0/6] arm64: untag user pointers passed to the kernel
From: Andrey Konovalov @ 2018-03-27 16:57 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Jonathan Corbet, Mark Rutland,
Robin Murphy, Al Viro, Andrey Konovalov, James Morse, Kees Cook,
Bart Van Assche, Kate Stewart, Greg Kroah-Hartman,
Thomas Gleixner, Philippe Ombredanne, Andrew Morton, Ingo Molnar,
Kirill A . Shutemov, Dan Williams, Aneesh Kumar K . V, Zi Yan,
linux-arm-kernel, linux-doc, linux-kernel, linux-mm
Cc: Dmitry Vyukov, Kostya Serebryany, Evgeniy Stepanov, Lee Smith,
Ramana Radhakrishnan, Jacob Bramley, Ruben Ayrapetyan
Hi!
arm64 has a feature called Top Byte Ignore, which allows to embed pointer
tags into the top byte of each pointer. Userspace programs (such as
HWASan, a memory debugging tool [1]) might use this feature and pass
tagged user pointers to the kernel through syscalls or other interfaces.
This patch makes a few of the kernel interfaces accept tagged user
pointers. The kernel is already able to handle user faults with tagged
pointers and has the untagged_addr macro, which this patchset reuses.
We're not trying to cover all possible ways the kernel accepts user
pointers in one patchset, so this one should be considered as a start.
Thanks!
[1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
Changes in RFC v2:
- Added "#ifndef untagged_addr..." fallback in linux/uaccess.h instead of
defining it for each arch individually.
- Updated Documentation/arm64/tagged-pointers.txt.
- Dropped “mm, arm64: untag user addresses in memory syscalls”.
- Rebased onto 3eb2ce82 (4.16-rc7).
Andrey Konovalov (6):
arm64: add type casts to untagged_addr macro
uaccess: add untagged_addr definition for other arches
arm64: untag user addresses in copy_from_user and others
mm, arm64: untag user addresses in mm/gup.c
lib, arm64: untag addrs passed to strncpy_from_user and strnlen_user
arm64: update Documentation/arm64/tagged-pointers.txt
Documentation/arm64/tagged-pointers.txt | 5 +++--
arch/arm64/include/asm/uaccess.h | 9 +++++++--
include/linux/uaccess.h | 4 ++++
lib/strncpy_from_user.c | 2 ++
lib/strnlen_user.c | 2 ++
mm/gup.c | 12 ++++++++++++
6 files changed, 30 insertions(+), 4 deletions(-)
--
2.17.0.rc0.231.g781580f067-goog
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC PATCH v2 1/6] arm64: add type casts to untagged_addr macro
From: Andrey Konovalov @ 2018-03-27 16:57 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Jonathan Corbet, Mark Rutland,
Robin Murphy, Al Viro, Andrey Konovalov, James Morse, Kees Cook,
Bart Van Assche, Kate Stewart, Greg Kroah-Hartman,
Thomas Gleixner, Philippe Ombredanne, Andrew Morton, Ingo Molnar,
Kirill A . Shutemov, Dan Williams, Aneesh Kumar K . V, Zi Yan,
linux-arm-kernel, linux-doc, linux-kernel, linux-mm
Cc: Dmitry Vyukov, Kostya Serebryany, Evgeniy Stepanov, Lee Smith,
Ramana Radhakrishnan, Jacob Bramley, Ruben Ayrapetyan
In-Reply-To: <cover.1522169685.git.andreyknvl@google.com>
This patch makes the untagged_addr macro accept all kinds of address types
(void *, unsigned long, etc.) and allows not to specify type casts in each
place where it is used. This is done by using __typeof__.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
arch/arm64/include/asm/uaccess.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index e66b0fca99c2..2d6451cbaa86 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -102,7 +102,8 @@ static inline unsigned long __range_ok(const void __user *addr, unsigned long si
* up with a tagged userland pointer. Clear the tag to get a sane pointer to
* pass on to access_ok(), for instance.
*/
-#define untagged_addr(addr) sign_extend64(addr, 55)
+#define untagged_addr(addr) \
+ ((__typeof__(addr))sign_extend64((__u64)(addr), 55))
#define access_ok(type, addr, size) __range_ok(addr, size)
#define user_addr_max get_fs
--
2.17.0.rc0.231.g781580f067-goog
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [RFC PATCH v2 4/6] mm, arm64: untag user addresses in mm/gup.c
From: Andrey Konovalov @ 2018-03-27 16:57 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Jonathan Corbet, Mark Rutland,
Robin Murphy, Al Viro, Andrey Konovalov, James Morse, Kees Cook,
Bart Van Assche, Kate Stewart, Greg Kroah-Hartman,
Thomas Gleixner, Philippe Ombredanne, Andrew Morton, Ingo Molnar,
Kirill A . Shutemov, Dan Williams, Aneesh Kumar K . V, Zi Yan,
linux-arm-kernel, linux-doc, linux-kernel, linux-mm
Cc: Dmitry Vyukov, Kostya Serebryany, Evgeniy Stepanov, Lee Smith,
Ramana Radhakrishnan, Jacob Bramley, Ruben Ayrapetyan
In-Reply-To: <cover.1522169685.git.andreyknvl@google.com>
mm/gup.c provides a kernel interface that accepts user addresses and
manipulates user pages directly (for example get_user_pages, that is used
by the futex syscall). Here we also need to handle the case of tagged user
pointers.
Untag addresses passed to this interface.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
mm/gup.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/mm/gup.c b/mm/gup.c
index 6afae32571ca..9c4afcf50dfa 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -386,6 +386,8 @@ struct page *follow_page_mask(struct vm_area_struct *vma,
struct page *page;
struct mm_struct *mm = vma->vm_mm;
+ address = untagged_addr(address);
+
*page_mask = 0;
/* make this handle hugepd */
@@ -647,6 +649,8 @@ static long __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
if (!nr_pages)
return 0;
+ start = untagged_addr(start);
+
VM_BUG_ON(!!pages != !!(gup_flags & FOLL_GET));
/*
@@ -801,6 +805,8 @@ int fixup_user_fault(struct task_struct *tsk, struct mm_struct *mm,
struct vm_area_struct *vma;
int ret, major = 0;
+ address = untagged_addr(address);
+
if (unlocked)
fault_flags |= FAULT_FLAG_ALLOW_RETRY;
@@ -854,6 +860,8 @@ static __always_inline long __get_user_pages_locked(struct task_struct *tsk,
long ret, pages_done;
bool lock_dropped;
+ start = untagged_addr(start);
+
if (locked) {
/* if VM_FAULT_RETRY can be returned, vmas become invalid */
BUG_ON(vmas);
@@ -1749,6 +1757,8 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
unsigned long flags;
int nr = 0;
+ start = untagged_addr(start);
+
start &= PAGE_MASK;
addr = start;
len = (unsigned long) nr_pages << PAGE_SHIFT;
@@ -1801,6 +1811,8 @@ int get_user_pages_fast(unsigned long start, int nr_pages, int write,
unsigned long addr, len, end;
int nr = 0, ret = 0;
+ start = untagged_addr(start);
+
start &= PAGE_MASK;
addr = start;
len = (unsigned long) nr_pages << PAGE_SHIFT;
--
2.17.0.rc0.231.g781580f067-goog
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [RFC PATCH v2 3/6] arm64: untag user addresses in copy_from_user and others
From: Andrey Konovalov @ 2018-03-27 16:57 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Jonathan Corbet, Mark Rutland,
Robin Murphy, Al Viro, Andrey Konovalov, James Morse, Kees Cook,
Bart Van Assche, Kate Stewart, Greg Kroah-Hartman,
Thomas Gleixner, Philippe Ombredanne, Andrew Morton, Ingo Molnar,
Kirill A . Shutemov, Dan Williams, Aneesh Kumar K . V, Zi Yan,
linux-arm-kernel, linux-doc, linux-kernel, linux-mm
Cc: Dmitry Vyukov, Kostya Serebryany, Evgeniy Stepanov, Lee Smith,
Ramana Radhakrishnan, Jacob Bramley, Ruben Ayrapetyan
In-Reply-To: <cover.1522169685.git.andreyknvl@google.com>
copy_from_user (and a few other similar functions) are used to copy data
from user memory into the kernel memory or vice versa. Since a user can
provided a tagged pointer to one of the syscalls that use copy_from_user,
we need to correctly handle such pointers.
Do this by untagging user pointers in access_ok and in __uaccess_mask_ptr.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
arch/arm64/include/asm/uaccess.h | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index 2d6451cbaa86..24a221678fe3 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -105,7 +105,8 @@ static inline unsigned long __range_ok(const void __user *addr, unsigned long si
#define untagged_addr(addr) \
((__typeof__(addr))sign_extend64((__u64)(addr), 55))
-#define access_ok(type, addr, size) __range_ok(addr, size)
+#define access_ok(type, addr, size) \
+ __range_ok(untagged_addr(addr), size)
#define user_addr_max get_fs
#define _ASM_EXTABLE(from, to) \
@@ -238,12 +239,15 @@ static inline void uaccess_enable_not_uao(void)
/*
* Sanitise a uaccess pointer such that it becomes NULL if above the
* current addr_limit.
+ * Also untag user pointers that have the top byte tag set.
*/
#define uaccess_mask_ptr(ptr) (__typeof__(ptr))__uaccess_mask_ptr(ptr)
static inline void __user *__uaccess_mask_ptr(const void __user *ptr)
{
void __user *safe_ptr;
+ ptr = untagged_addr(ptr);
+
asm volatile(
" bics xzr, %1, %2\n"
" csel %0, %1, xzr, eq\n"
--
2.17.0.rc0.231.g781580f067-goog
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [RFC PATCH v2 6/6] arm64: update Documentation/arm64/tagged-pointers.txt
From: Andrey Konovalov @ 2018-03-27 16:57 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Jonathan Corbet, Mark Rutland,
Robin Murphy, Al Viro, Andrey Konovalov, James Morse, Kees Cook,
Bart Van Assche, Kate Stewart, Greg Kroah-Hartman,
Thomas Gleixner, Philippe Ombredanne, Andrew Morton, Ingo Molnar,
Kirill A . Shutemov, Dan Williams, Aneesh Kumar K . V, Zi Yan,
linux-arm-kernel, linux-doc, linux-kernel, linux-mm
Cc: Dmitry Vyukov, Kostya Serebryany, Evgeniy Stepanov, Lee Smith,
Ramana Radhakrishnan, Jacob Bramley, Ruben Ayrapetyan
In-Reply-To: <cover.1522169685.git.andreyknvl@google.com>
Add a note that work on passing tagged user pointers to the kernel via
syscalls has started, but might not be complete yet.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
Documentation/arm64/tagged-pointers.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/arm64/tagged-pointers.txt b/Documentation/arm64/tagged-pointers.txt
index a25a99e82bb1..361481283f00 100644
--- a/Documentation/arm64/tagged-pointers.txt
+++ b/Documentation/arm64/tagged-pointers.txt
@@ -35,8 +35,9 @@ Using non-zero address tags in any of these locations may result in an
error code being returned, a (fatal) signal being raised, or other modes
of failure.
-For these reasons, passing non-zero address tags to the kernel via
-system calls is forbidden, and using a non-zero address tag for sp is
+Some initial work for supporting non-zero address tags passed to the
+kernel via system calls has been done, but the kernel doesn't provide
+any guarantees at this point. Using a non-zero address tag for sp is
strongly discouraged.
Programs maintaining a frame pointer and frame records that use non-zero
--
2.17.0.rc0.231.g781580f067-goog
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [RFC PATCH v2 2/6] uaccess: add untagged_addr definition for other arches
From: Andrey Konovalov @ 2018-03-27 16:57 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Jonathan Corbet, Mark Rutland,
Robin Murphy, Al Viro, Andrey Konovalov, James Morse, Kees Cook,
Bart Van Assche, Kate Stewart, Greg Kroah-Hartman,
Thomas Gleixner, Philippe Ombredanne, Andrew Morton, Ingo Molnar,
Kirill A . Shutemov, Dan Williams, Aneesh Kumar K . V, Zi Yan,
linux-arm-kernel, linux-doc, linux-kernel, linux-mm
Cc: Dmitry Vyukov, Kostya Serebryany, Evgeniy Stepanov, Lee Smith,
Ramana Radhakrishnan, Jacob Bramley, Ruben Ayrapetyan
In-Reply-To: <cover.1522169685.git.andreyknvl@google.com>
To allow arm64 syscalls accept tagged pointers from userspace, we must
untag them when they are passed to the kernel. Since untagging is done in
generic parts of the kernel (like the mm subsystem), the untagged_addr
macro should be defined for all architectures.
Define it as a noop for other architectures besides arm64.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
include/linux/uaccess.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
index efe79c1cdd47..c045b4eff95e 100644
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@@ -13,6 +13,10 @@
#include <asm/uaccess.h>
+#ifndef untagged_addr
+#define untagged_addr(addr) addr
+#endif
+
/*
* Architectures should provide two primitives (raw_copy_{to,from}_user())
* and get rid of their private instances of copy_{to,from}_user() and
--
2.17.0.rc0.231.g781580f067-goog
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox