Re: [PATCH v3 05/11] dt-bindings: i3c: Document core bindings

[Boris Brezillon]

Hi Rob,

On Mon, 26 Mar 2018 17:24:58 -0500
Rob Herring  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 @,,  
> 
> 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@d04 {
> > +   compatible = "cdns,i3c-master";
> > +   clocks = <&coreclock>, <&i3csysclock>;
> > +   clock-names = "pclk", "sysclk";
> > +   interrupts = <3 0>;
> > +   reg = <0x0d04 0x1000>;
> > +   #address-cells = <3>;
> > +   #size-cells = <0>;
> > +
> > +   status = "okay";
> > +   i2c-scl-frequency = <10>;
> > +
> > +   /* I2C device. */
> > +   nunchuk: nunchuk@52 {
> > +   compatible = "nintendo,nunchuk";
> > +   reg = <0x52 0x8010 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Question] Documentation/features: More automation/scripting help?

[Andrea Parri]

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.  -- |   Optimi

Re: [PATCH] docs/memory-barriers.txt: Fix broken DMA vs MMIO ordering example

[Sinan Kaya]

+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 
>> Cc: Arnd Bergmann 
>> Cc: Jason Gunthorpe 
>> Cc: "Paul E. McKenney" 
>> Cc: Peter Zijlstra 
>> Cc: Ingo Molnar 
>> Cc: Jonathan Corbet 
>> Reported-by: Sinan Kaya 
>> Signed-off-by: Will Deacon 
> 
> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Documentation/wimax: Point dead link to working copy

[Sanjeev Gupta]

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 
---
 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/8] doc: Add doc for the Ingenic TCU hardware

[Paul Cercueil]

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 
---
 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 ..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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Documentation/thermal: Check links and convert to https

[Sanjeev Gupta]

All links working.

Signed-off-by: Sanjeev Gupta 
---
 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 
 
 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/8] Ingenic JZ47xx Timer/Counter Unit drivers

[Paul Cercueil]

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/8] dt-bindings: ingenic: Add DT bindings for TCU clocks

[Paul Cercueil]

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  
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 


Great! Is that for the whole patchset or just this one patch?


Signed-off-by: Paul Cercueil 
Reviewed-by: Rob Herring 
---
 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 ..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_LASTJZ4740_CLK_WDT
+
+#define JZ4770_CLK_OST 9
+#define JZ4770_CLK_LASTJZ4770_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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/8] dt-bindings: Add doc for the Ingenic TCU drivers

[Paul Cercueil]

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 
---
 .../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 ..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 .
+
+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 ..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,-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 ..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 paren

Re: [PATCH v4 0/8] Ingenic JZ47xx Timer/Counter Unit drivers

[Daniel Lezcano]

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 :/


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 7/8] clocksource: Add a new timer-ingenic driver

[Paul Cercueil]

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 
---
 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 ..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 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#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 > 0x)
+   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;

Re: [PATCH v4 4/8] dt-bindings: Add doc for the Ingenic TCU drivers

[Paul Cercueil]

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 
---
 .../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 ..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 .
+
+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 ..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,-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 ..5742c3f21550
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
@@ -0,0 

[PATCH] Documentation/usb: Fix dead links and convert others to https

[Sanjeev Gupta]

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 
---
 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 g...@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 h...@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
   fr...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 7/8] clocksource: Add a new timer-ingenic driver

[Daniel Lezcano]

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 
>>> ---
>>>  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.
[ ... ]

-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/8] dt-bindings: Add doc for the Ingenic TCU drivers

[Rob Herring]

On Wed, Mar 28, 2018 at 10:33 AM, Paul Cercueil  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 
>>> ---
>>>  .../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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 05/11] dt-bindings: i3c: Document core bindings

[Rob Herring]

On Wed, Mar 28, 2018 at 3:19 AM, Boris Brezillon
 wrote:
> Hi Rob,
>
> On Mon, 26 Mar 2018 17:24:58 -0500
> Rob Herring  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 @,,
>>
>> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 05/11] dt-bindings: i3c: Document core bindings

[Boris Brezillon]

On Wed, 28 Mar 2018 11:42:07 -0500
Rob Herring  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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs/memory-barriers.txt: Fix broken DMA vs MMIO ordering example

[Tony Luck]

On Wed, Mar 28, 2018 at 6:02 AM, Sinan Kaya  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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs/memory-barriers.txt: Fix broken DMA vs MMIO ordering example

[Peter Zijlstra]

On Wed, Mar 28, 2018 at 10:57:11AM -0700, Tony Luck wrote:
> On Wed, Mar 28, 2018 at 6:02 AM, Sinan Kaya  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.

Just to nitpick, regular release semantics don't guarantee anything like
that, but ia64 never actually got around to implementing proper release
and it's a full barrier and thus what you say is true.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/8] dt-bindings: ingenic: Add DT bindings for TCU clocks

[Mathieu Malaterre]

On Wed, Mar 28, 2018 at 5:04 PM, Paul Cercueil  wrote:
> 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 
>> 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 
>
>
> Great! Is that for the whole patchset or just this one patch?

The sentence just above was "whole series"  :) so yes that was for the
whole series. Technically I only tested it on JZ4780, I hope this is
acceptable for the tag.



>
>>> Signed-off-by: Paul Cercueil 
>>> Reviewed-by: Rob Herring 
>>> ---
>>>  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 ..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_LASTJZ4740_CLK_WDT
>>> +
>>> +#define JZ4770_CLK_OST 9
>>> +#define JZ4770_CLK_LASTJZ4770_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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v12 07/22] selftests/vm: fixed bugs in pkey_disable_clear()

[Thiago Jung Bauermann]

Dave Hansen  writes:

> On 02/21/2018 05:55 PM, Ram Pai wrote:
>> --- a/tools/testing/selftests/vm/protection_keys.c
>> +++ b/tools/testing/selftests/vm/protection_keys.c
>> @@ -461,7 +461,7 @@ void pkey_disable_clear(int pkey, int flags)
>>  pkey, pkey, pkey_rights);
>>  pkey_assert(pkey_rights >= 0);
>>
>> -pkey_rights |= flags;
>> +pkey_rights &= ~flags;
>>
>>  ret = pkey_set(pkey, pkey_rights, 0);
>>  /* pkey_reg and flags have the same format */
>> @@ -475,7 +475,7 @@ void pkey_disable_clear(int pkey, int flags)
>>  dprintf1("%s(%d) pkey_reg: 0x%016lx\n", __func__,
>>  pkey, rdpkey_reg());
>>  if (flags)
>> -assert(rdpkey_reg() > orig_pkey_reg);
>> +assert(rdpkey_reg() < orig_pkey_reg);
>>  }
>>
>>  void pkey_write_allow(int pkey)
>
> This seems so horribly wrong that I wonder how it worked in the first
> place.  Any idea?

The code simply wasn't used. pkey_disable_clear() is called by
pkey_write_allow() and pkey_access_allow(), but before this patch series
nothing called either of these functions.


--
Thiago Jung Bauermann
IBM Linux Technology Center

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v12 07/22] selftests/vm: fixed bugs in pkey_disable_clear()

[Dave Hansen]

On 03/28/2018 01:47 PM, Thiago Jung Bauermann wrote:
>>> if (flags)
>>> -   assert(rdpkey_reg() > orig_pkey_reg);
>>> +   assert(rdpkey_reg() < orig_pkey_reg);
>>>  }
>>>
>>>  void pkey_write_allow(int pkey)
>> This seems so horribly wrong that I wonder how it worked in the first
>> place.  Any idea?
> The code simply wasn't used. pkey_disable_clear() is called by
> pkey_write_allow() and pkey_access_allow(), but before this patch series
> nothing called either of these functions.
> 

Ahh, that explains it.  Can that get stuck in the changelog, please?
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v12 07/22] selftests/vm: fixed bugs in pkey_disable_clear()

[Thiago Jung Bauermann]

Dave Hansen  writes:

> On 03/28/2018 01:47 PM, Thiago Jung Bauermann wrote:
if (flags)
 -  assert(rdpkey_reg() > orig_pkey_reg);
 +  assert(rdpkey_reg() < orig_pkey_reg);
  }

  void pkey_write_allow(int pkey)
>>> This seems so horribly wrong that I wonder how it worked in the first
>>> place.  Any idea?
>> The code simply wasn't used. pkey_disable_clear() is called by
>> pkey_write_allow() and pkey_access_allow(), but before this patch series
>> nothing called either of these functions.
>> 
>
> Ahh, that explains it.  Can that get stuck in the changelog, please?

Yes, will be in the next version.

-- 
Thiago Jung Bauermann
IBM Linux Technology Center

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] perf: riscv: preliminary RISC-V support

[Palmer Dabbelt]

On Wed, 28 Mar 2018 15:31:30 PDT (-0700), s...@sifive.com wrote:

Also, core IDs and socket IDs are wrong in perf report:


It looks like for this we need the stuff in topology.h.  I've cobbled something 
together quickly for Alex to use for now to see if that fixes other problems, 
I'll submit a sane version when we can.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] perf: riscv: preliminary RISC-V support

[Alan Kao]

Hi Alex,

I'm appreciated for your reply and tests.

On Wed, Mar 28, 2018 at 03:58:41PM -0700, Alex Solomatnikov wrote:
> Did you test this code?

I did test this patch on QEMU's virt model with multi-hart, which is the only
RISC-V machine I have for now.  But as I mentioned in 
https://github.com/riscv/riscv-qemu/pull/115 , the hardware counter support
in QEMU is not fully conformed to the 1.10 Priv-Spec, so I had to slightly
tweak the code to make reading work.

Specifically, the read to cycle and instret in QEMU looks like this:
...
case CSR_INSTRET:
case CSR_CYCLE:
//  if (ctr_ok) {
return cpu_get_host_ticks();
//  }
break;
...
and the two lines of comment was the tweak.

On such environment, I did not get anything unexpected.  No matter which of them
is requested, QEMU returns the host's tick.

> 
> I got funny numbers when I tried to run it on HiFive Unleashed:
> 
> perf stat mem-latency
> ...
> 
>  Performance counter stats for 'mem-latency':
> 
> 157.907000  task-clock (msec) #0.940 CPUs utilized
> 
>  1  context-switches  #0.006 K/sec
> 
>  1  cpu-migrations#0.006 K/sec
> 
>   4102  page-faults   #0.026 M/sec
> 
>  157923752  cycles#1.000 GHz
> 
> 9223372034948899840  instructions  # 58403957087.78  insn
> per cycle
>  branches
> 
>  branch-misses
> 
> 
>0.168046000 seconds time elapsed
> 
> 
> Tracing read_counter(), I see this:
> 
> Jan  1 00:41:50 buildroot user.info kernel: [ 2510.058809] CPU 3:
> read_counter  idx=0 val=2528358954912
> Jan  1 00:41:50 buildroot user.info kernel: [ 2510.063339] CPU 3:
> read_counter  idx=1 val=53892244920
> Jan  1 00:41:50 buildroot user.info kernel: [ 2510.118160] CPU 3:
> read_counter  idx=0 val=2528418303035
> Jan  1 00:41:50 buildroot user.info kernel: [ 2510.122694] CPU 3:
> read_counter  idx=1 val=53906699665
> Jan  1 00:41:50 buildroot user.info kernel: [ 2510.216736] CPU 1:
> read_counter  idx=0 val=2528516878664
> Jan  1 00:41:50 buildroot user.info kernel: [ 2510.221270] CPU 1:
> read_counter  idx=1 val=51986369142
> 
> It looks like the counter values from different cores are subtracted and
> wraparound occurs.
> 

Thanks for the hint.  It makes sense.  9223372034948899840 is 7fff8e66a400,
which should be a wraparound with the mask I set (63-bit) in the code.

I will try this direction.  Ideally, we can solve it by explicitly syncing the
hwc->prev_count when a cpu migration event happens.

> 
> Also, core IDs and socket IDs are wrong in perf report:
> 

As Palmer has replied to this, I have no comment here.

> perf report --header -I
> Error:
> The perf.data file has no samples!
> # 
> # captured on: Thu Jan  1 02:52:07 1970
> # hostname : buildroot
> # os release : 4.15.0-00045-g0d7c030-dirty
> # perf version : 4.15.0
> # arch : riscv64
> # nrcpus online : 4
> # nrcpus avail : 5
> # total memory : 8188340 kB
> # cmdline : /usr/bin/perf record -F 1000 lat_mem_rd -P 1 -W 1 -N 1 -t 10
> # event : name = cycles:ppp, , size = 112, { sample_period, sample_freq } =
> 1000, sample_type = IP|TID|TIME|PERIOD, disabled = 1, inherit = 1, mmap =
> 1, comm = 1, freq = 1, enable_on_exec = 1, task = 1, precise_ip = 3,
> sample_id_all = 1, exclude_guest = 1, mmap2 = 1, comm_exec = 1
> # sibling cores   : 1
> # sibling cores   : 2
> # sibling cores   : 3
> # sibling cores   : 4
> # sibling threads : 1
> # sibling threads : 2
> # sibling threads : 3
> # sibling threads : 4
> # CPU 0: Core ID -1, Socket ID -1
> # CPU 1: Core ID 0, Socket ID -1
> # CPU 2: Core ID 0, Socket ID -1
> # CPU 3: Core ID 0, Socket ID -1
> # CPU 4: Core ID 0, Socket ID -1
> # pmu mappings: cpu = 4, software = 1
> # CPU cache info:
> #  L1 Instruction  32K [1]
> #  L1 Data 32K [1]
> #  L1 Instruction  32K [2]
> #  L1 Data 32K [2]
> #  L1 Instruction  32K [3]
> #  L1 Data 32K [3]
> # missing features: TRACING_DATA BUILD_ID CPUDESC CPUID NUMA_TOPOLOGY
> BRANCH_STACK GROUP_DESC AUXTRACE STAT
> # 
> 
> 
> Alex
>

Many thanks,
Alan

> On Mon, Mar 26, 2018 at 12:57 AM, Alan Kao  wrote:
> 
> > This patch provide a basic PMU, riscv_base_pmu, which supports two
> > general hardware event, instructions and cycles.  Furthermore, this
> > PMU serves as a reference implementation to ease the portings in
> > the future.
> >
> > riscv_base_pmu should be able to run on any RISC-V machine that
> > conforms to the Priv-Spec.  Note that the latest qemu model hasn't
> > fully support a proper behavior of Priv-Spec 1.10 yet, but work
> > around should be easy with very small fixes.  Please check
> > https://github.com/riscv/riscv-qemu/pull/115 for future updates.
> >
> > Cc: Nick Hu 
> > Cc: Greentime Hu 
> > Signed-off-by: Alan Kao 
> > ---
> >  arch/riscv/Kconfig  |  12 +
> >  arch/riscv/include/asm