Re: [RFC 0/2] Add a new translation tool scripts/trslt.py

[Federico Vaga]

Hi,

Yes, you are touching a good point where things can be improved. I admit that I
did not have a look at the code yet, if not very quickly. Perhaps I'm missing
somethin. However, let me give you my two cents based on what I usually do.

I do not like the idea of adding tags to the file and having tools to modify it.
I would prefer to keep the text as clean as possible.

Instead, what can be done without touching manipulating the text file is to do
something like this:

# Take the commit ID of the last time a document has translated
LAST_TRANS=$(git log -n 1 --oneline Documentation/translations// | 
cut -d " " -f 1)

# Take the history of the same file in the main Documentation tree
git log --oneline $LAST_TRANS..doc/docs-next Documentation/

This will give you the list of commits that changed , and that
probably need to be translated. The problem of this approach is that by the time
you submit a translation, other people may change the very same files. The
correctness of this approach depends on patch order in docs-next, and this can't
be guaranteed.

So, instead of reling on LAST_DIR, I rely on a special git branch that acts as
marker. But this works only for me and not for other translator of the same
languages, so you can get troubles also in this case.

What we can actually do is to exploit the git commit message to store the tag
you mentioned. Hence, we can get the last Id with something like this:

LAST_ID=$(git log -n 1 Documentation/translations// | grep -E 
"Translated-on-top-of: commit [0-9a-f]{12}")

The ID we store in the tag does not need to be the commit ID of the last change
to , but just the commit on which you were when you did the
translation. This because it will simplify the management of this tag when
translating multiple files/patches in a single patch (to avoid to spam the
mailing list with dozens of small patches).

On Mon, Apr 12, 2021 at 03:04:03PM +0800, Wu XiangCheng wrote:

Hi all,

This set of patches aim to add a new translation tool - trslt.py, which
can control the transltions version corresponding to source files.

For a long time, kernel documentation translations lacks a way to control the
version corresponding to the source files. If you translate a file and then
someone updates the source file, there will be a problem. It's hard to know
which version the existing translation corresponds to, and even harder to sync
them.

The common way now is to check the date, but this is not exactly accurate,
especially for documents that are often updated. And some translators write
corresponding commit ID in the commit log for reference, it is a good way,
but still a little troublesome.

Thus, the purpose of ``trslt.py`` is to add a new annotating tag to the file
to indicate corresponding version of the source file::

.. translation_origin_commit: 

The script will automatically copy file and generate tag when creating new
translation, and give update suggestions based on those tags when updating
translations.

More details please read doc in [Patch 2/2].

Still need working:
- improve verbose mode
- test on more python 3.x version
- only support linux now, need test on Mac OS, nonsupport Windows
 due to '\'

Any suggestion is welcome!

Thanks!

Wu XiangCheng (2):
 scripts: Add new translation tool trslt.py
 docs: doc-guide: Add document for scripts/trslt.py

Documentation/doc-guide/index.rst |   1 +
Documentation/doc-guide/trslt.rst | 233 ++
scripts/trslt.py  | 267 ++
3 files changed, 501 insertions(+)
create mode 100644 Documentation/doc-guide/trslt.rst
create mode 100755 scripts/trslt.py

--
2.20.1

[PATCH] doc:it_IT: align Italian documentation

[Federico Vaga]

Translation for the following patches

commit 7dfbea4c468c ("scripts: remove namespace.pl")
commit 1a63f9cce7b7 ("docs: Remove make headers_check from checklist")
commit 1e013ff7cb54 ("docs: Document cross-referencing using relative path")
commit 0be1511f516e ("Documentation: doc-guide: fixes to sphinx.rst")
commit 911358401284 ("kernel-doc: Fix example in Nested structs/unions")
commit 875f82cb374b ("Documentation/submitting-patches: Extend commit message 
layout description")
commit 78f101a1b258 ("Documentation/submitting-patches: Add blurb about 
backtraces in commit messages")
commit f0ea149eee6b ("docs: submitting-patches: Emphasise the requirement to 
Cc: stable when using Fixes: tag")
commit 05a5f51ca566 ("Documentation: Replace lkml.org links with lore")
commit 9bf19b78a203 ("Documentation/submitting-patches: Document the SoB chain")
commit b7592e5b82db ("docs: Remove the Microsoft rhetoric")
commit 26606ce072d4 ("coding-style.rst: Avoid comma statements")
commit dd58e649742a ("docs: Make syscalls' helpers naming consistent")
commit 460cd17e9f7d ("net: switch to the kernel.org patchwork instance")
commit 163ba35ff371 ("doc: use KCFLAGS instead of EXTRA_CFLAGS to pass flags 
from command line")
commit 0ef597c3ac49 ("docs: remove mention of ENABLE_MUST_CHECK")
commit f8408264c77a ("drivers: Remove CONFIG_OPROFILE support")
commit 0653c358d2dc ("scsi: Drop gdth driver")
commit f8ae7bbec726 ("net: x25_asy: Delete the x25_asy driver")
commit cf6d6fc27936 ("docs: process/howto.rst: make sections on bug reporting 
match practice")
commit da514157c4f0 ("docs: make reporting-bugs.rst obsolete")
commit 4f8af077a02e ("docs: Fix reST markup when linking to sections")
commit 3a4928cf5e3c ("Documentation: kernel-hacking: change 'current()' to 
'current'")
commit c170f2eb9648 ("docs: Document cross-referencing between documentation 
pages")

Signed-off-by: Federico Vaga 
---
 .../translations/it_IT/doc-guide/sphinx.rst   | 47 +
 .../it_IT/kernel-hacking/hacking.rst  |  2 +-
 .../it_IT/kernel-hacking/locking.rst  | 12 +--
 .../translations/it_IT/process/4.Coding.rst   |  9 +-
 .../it_IT/process/adding-syscalls.rst |  2 +-
 .../it_IT/process/coding-style.rst| 22 -
 .../translations/it_IT/process/howto.rst  | 25 +++--
 .../it_IT/process/magic-number.rst|  2 -
 .../it_IT/process/submit-checklist.rst|  7 +-
 .../it_IT/process/submitting-patches.rst  | 98 +++
 10 files changed, 154 insertions(+), 72 deletions(-)

diff --git a/Documentation/translations/it_IT/doc-guide/sphinx.rst 
b/Documentation/translations/it_IT/doc-guide/sphinx.rst
index 090d2949d345..0046d75d9a70 100644
--- a/Documentation/translations/it_IT/doc-guide/sphinx.rst
+++ b/Documentation/translations/it_IT/doc-guide/sphinx.rst
@@ -330,17 +330,17 @@ la lista di celle che compongono la *riga* stessa. Fanno 
eccezione i *commenti*
 - head col 3
 - head col 4
 
-  * - column 1
+  * - row 1
 - field 1.1
 - field 1.2 with autospan
 
-  * - column 2
+  * - row 2
 - field 2.1
 - :rspan:`1` :cspan:`1` field 2.2 - 3.3
 
   * .. _`it last row`:
 
-- column 3
+- row 3
 
 Che verrà rappresentata nel seguente modo:
 
@@ -352,37 +352,46 @@ Che verrà rappresentata nel seguente modo:
 - head col 3
 - head col 4
 
-  * - column 1
+  * - row 1
 - field 1.1
 - field 1.2 with autospan
 
-  * - column 2
+  * - row 2
 - field 2.1
 - :rspan:`1` :cspan:`1` field 2.2 - 3.3
 
   * .. _`it last row`:
 
-- column 3
+- row 3
 
 Riferimenti incrociati
 --
 
-Per fare dei riferimenti incrociati da una pagina ad un'altra
-specificando il percorso a partire dalla cartella *Documentation*.
-Per esempio, se volete aggiungere un riferimento a questa pagina
-(l'estensione .rst è opzionale)::
+Aggiungere un riferimento incrociato da una pagina della
+documentazione ad un'altra può essere fatto scrivendo il percorso al
+file corrispondende, non serve alcuna sintassi speciale. Si possono
+usare sia percorsi assoluti che relativi. Quelli assoluti iniziano con
+"documentation/". Per esempio, potete fare riferimento a questo
+documento in uno dei seguenti modi (da notare che l'estensione
+``.rst`` è necessaria)::
 
-See Documentation/translations/it_IT/doc-guide/sphinx.rst.
+Vedere Documentation/doc-guide/sphinx.rst. Questo funziona sempre
+Guardate pshinx.rst, che si trova nella stessa cartella.
+Leggete ../sphinx.rst, che si trova nella cartella precedente.
 
-Se preferite usare un percorso relative allora vi serve la direttiva
-Sphinx ``doc``.  Per esemp

Re: [PATCH v3 6/8] docs: replace transation references for reporting-bugs.rst

[Federico Vaga]

On 2021-04-09 14:47, Mauro Carvalho Chehab wrote:

Changeset d2ce285378b0 ("docs: make reporting-issues.rst official and
delete reporting-bugs.rst")
dropped reporting-bugs.rst, in favor of reporting-issues.rst, but
translations still need to be updated, in order to point to the
new file.

Fixes: d2ce285378b0 ("docs: make reporting-issues.rst official and
delete reporting-bugs.rst")
Acked-by: Wu XiangCheng 
Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/translations/it_IT/process/howto.rst    | 2 +-


Acked-by: Federico Vaga 


 Documentation/translations/ja_JP/howto.rst| 2 +-
 Documentation/translations/zh_CN/SecurityBugs | 2 +-
 .../translations/zh_CN/admin-guide/reporting-issues.rst   | 4 ++--
 Documentation/translations/zh_CN/process/howto.rst| 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)


--
Federico Vaga

Re: [PATCH v2 17/19] docs: replace transation references for reporting-bugs.rst

[Federico Vaga]

On 2021-04-07 10:20, Mauro Carvalho Chehab wrote:

Changeset d2ce285378b0 ("docs: make reporting-issues.rst official and
delete reporting-bugs.rst")
dropped reporting-bugs.rst, in favor of reporting-issues.rst, but
translations still need to be updated, in order to point to the
new file.

Fixes: d2ce285378b0 ("docs: make reporting-issues.rst official and
delete reporting-bugs.rst")
Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/translations/it_IT/process/howto.rst    | 2 +-


Acked-by: Federico Vaga 


 Documentation/translations/ja_JP/howto.rst| 2 +-
 Documentation/translations/zh_CN/SecurityBugs | 2 +-
 .../translations/zh_CN/admin-guide/reporting-issues.rst   | 4 ++--
 Documentation/translations/zh_CN/process/howto.rst| 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)


--
Federico Vaga
http://www.federicovaga.it/

Re: [PATCH v2 17/19] docs: replace transation references for reporting-bugs.rst

[Federico Vaga]

On 2021-04-07 11:39, Mauro Carvalho Chehab wrote:

Em Wed, 7 Apr 2021 10:52:14 +0200
Thorsten Leemhuis  escreveu:


On 07.04.21 10:20, Mauro Carvalho Chehab wrote:
> Changeset d2ce285378b0 ("docs: make reporting-issues.rst official and delete 
reporting-bugs.rst")
> dropped reporting-bugs.rst, in favor of reporting-issues.rst, but
> translations still need to be updated, in order to point to the
> new file.
>
> Fixes: d2ce285378b0 ("docs: make reporting-issues.rst official and delete 
reporting-bugs.rst")
> Signed-off-by: Mauro Carvalho Chehab 

Well, yeah, might be the right thing to do. But FWIW: when I recently
submitted the change that became d2ce285378b0 I actually pointed out
that it breaks some of the translations. Back then I considered to do
what you did with this patch, but among others got a reply from 
Jonathan

who said "let the translators catch up on their own time". For details
see this thread:
https://lore.kernel.org/linux-doc/87h7krksvu@meer.lwn.net/


Hmm... at the e-mail you mentioned, Jon commented that:

"None of the broken references actually generate warnings"


I take the occasion to highlight it.

If there are trivial fixes due to broken references introduced by a 
patch, then fixing the translation is recommended (as you fix all 
instances of a function if you change its arguments), and you do not 
need to know the target language to do it. Any other change to the text 
body is left to translators.



That's actually not the case: they do generate warnings if
the Kernel is built with CONFIG_WARN_MISSING_DOCUMENTS:

Documentation/translations/zh_CN/admin-guide/reporting-issues.rst:
Documentation/admin-guide/reporting-bugs.rst
Documentation/translations/zh_CN/admin-guide/reporting-issues.rst:
Documentation/admin-guide/reporting-bugs.rst

As it will call the ./scripts/documentation-file-ref-check.

That's basically why I detected and submitted a fix ;-)

Thanks,
Mauro


--
Federico Vaga
http://www.federicovaga.it/

Re: [PATCH] doc: use KCFLAGS instead of EXTRA_CFLAGS to pass flags from command line

[Federico Vaga]

On 2021-02-21 16:25, Masahiro Yamada wrote:

You should use KCFLAGS to pass additional compiler flags from the
command line. Using EXTRA_CFLAGS is wrong.

EXTRA_CFLAGS is supposed to specify flags applied only to the current
Makefile (and now deprecated in favor of ccflags-y).

It is still used in arch/mips/kvm/Makefile (and possibly in external
modules too). Passing EXTRA_CFLAGS from the command line overwrites
it and breaks the build.

I also fixed drivers/gpu/drm/tilcdc/Makefile because commit 
816175dd1fd7

("drivers/gpu/drm/tilcdc: Makefile, only -Werror when no -W* in
EXTRA_CFLAGS") was based on the same misunderstanding.

Signed-off-by: Masahiro Yamada 
---

 Documentation/process/4.Coding.rst| 2 +-
 Documentation/process/submit-checklist.rst| 2 +-
 Documentation/translations/it_IT/process/4.Coding.rst | 2 +-
 Documentation/translations/it_IT/process/submit-checklist.rst | 2 +-
 Documentation/translations/zh_CN/process/4.Coding.rst | 2 +-
 drivers/gpu/drm/tilcdc/Makefile   | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)


Acked-by: Federico Vaga 

--
Federico Vaga
http://www.federicovaga.it/

Re: [PATCH 17/18] drivers: Remove CONFIG_OPROFILE support

[Federico Vaga]

On 2021-01-14 12:35, Viresh Kumar wrote:

The "oprofile" user-space tools don't use the kernel OPROFILE support
any more, and haven't in a long time. User-space has been converted to
the perf interfaces.

Remove kernel's old oprofile support.

Suggested-by: Christoph Hellwig 
Suggested-by: Linus Torvalds 
Signed-off-by: Viresh Kumar 
---
 Documentation/RCU/NMI-RCU.rst |   3 +-
 .../admin-guide/kernel-parameters.txt |  14 -
 Documentation/process/magic-number.rst|   1 -
 .../it_IT/process/magic-number.rst|   1 -


Of course that's OK for the italian transation

--
Federico Vaga

[PATCH v3] doc:it_IT: align Italian documentation

[Federico Vaga]

Translation for the following patches

commit 0aa78b105f57 ("Documentation/changes: Raise minimum supported binutils 
version to 2.23")
commit 7d7178873560 ("Documentation: include sign off for reverts")
commit 905705a8fd43 ("docs: programming-languages: refresh blurb on clang 
support")
commit 5ff4aa70bf34 ("docs: submitting-patches: use :doc: for references")
commit 030f066f677f ("docs: submitting-patches: describe preserving review/test 
tags")
commit 68e4cd17e218 ("docs: deprecated.rst: Add zero-length and one-element 
arrays")
commit 5429ef62bcf3 ("compiler/gcc: Raise minimum GCC version for kernel builds 
to 4.8")
commit 5b5bbb8cc51b ("docs: process: Add an example for creating a fixes tag")
commit 858e6845654d ("docs: dt: convert submitting-patches.txt to ReST format")
commit cca73e4946c4 ("docs: Correct the release date of 5.2 stable")
commit c170f2eb9648 ("docs: Document cross-referencing between documentation 
pages")
commit 7c8b9e3000f8 ("kernel-doc: Update "cross-referencing from rST" section 
to use automarkup")
commit 27def953b63b ("docs: deprecated.rst: Expand str*cpy() replacement notes")
commit 17dca0502314 ("docs: deprecated.rst: Update zero-length/one-element 
arrays section")
commit 3519c4d6e08e ("Documentation: add minimum clang/llvm version")
commit 0bddd227f3dc ("Documentation: update for gcc 4.9 requirement")
commit 9f364b605f34 ("submitting-patches.rst: presume git will be used")
commit 4ebdf7be21d6 ("Documentation/maintainer: rehome sign-off process")
commit 7433ff33e8ba ("Documentation/process: expand plain-text advice")
commit eb45fb2fb16d ("docs: process: Add cross-link to security-bugs")
commit bdc48fa11e46 ("checkpatch/coding-style: deprecate 80-column warning")
commit f67281a72b30 ("Documentation: process: step 2: Link to email list fixed")

Signed-off-by: Federico Vaga 
---
 v2: added missing underscore in a link
 v3: added 2 translation's alignments

 .../it_IT/doc-guide/kernel-doc.rst|  30 +-
 .../translations/it_IT/doc-guide/sphinx.rst   |  20 ++
 .../translations/it_IT/process/2.Process.rst  |   4 +-
 .../translations/it_IT/process/changes.rst|  22 +-
 .../it_IT/process/coding-style.rst|  26 +-
 .../translations/it_IT/process/deprecated.rst | 147 -
 .../it_IT/process/email-clients.rst   |   5 +
 .../it_IT/process/programming-language.rst|   8 +-
 .../it_IT/process/submitting-patches.rst  | 297 +-
 9 files changed, 296 insertions(+), 263 deletions(-)

diff --git a/Documentation/translations/it_IT/doc-guide/kernel-doc.rst 
b/Documentation/translations/it_IT/doc-guide/kernel-doc.rst
index 524ad86cadbb..009cdac014b6 100644
--- a/Documentation/translations/it_IT/doc-guide/kernel-doc.rst
+++ b/Documentation/translations/it_IT/doc-guide/kernel-doc.rst
@@ -419,26 +419,24 @@ del `dominio Sphinx per il C`_.
 Riferimenti usando reStructuredText
 ~~~
 
-Per fare riferimento a funzioni e tipi di dato definiti nei commenti kernel-doc
-all'interno dei documenti reStructuredText, utilizzate i riferimenti dal
-`dominio Sphinx per il C`_. Per esempio::
+Nei documenti reStructuredText non serve alcuna sintassi speciale per
+fare riferimento a funzioni e tipi definiti nei commenti
+kernel-doc. Sarà sufficiente terminare i nomi di funzione con ``()``,
+e scrivere ``struct``, ``union``, ``enum``, o ``typedef`` prima di un
+tipo. Per esempio::
 
-  See function :c:func:`foo` and struct/union/enum/typedef :c:type:`bar`.
+  See foo()
+  See struct foo.
+  See union bar.
+  See enum baz.
+  See typedef meh.
 
-Nonostante il riferimento ai tipi di dato funzioni col solo nome,
-ovvero senza specificare struct/union/enum/typedef, potreste preferire il
-seguente::
+Tuttavia, la personalizzazione dei collegamenti è possibile solo con
+la seguente sintassi::
 
-  See :c:type:`struct foo `.
-  See :c:type:`union bar `.
-  See :c:type:`enum baz `.
-  See :c:type:`typedef meh `.
+  See :c:func:`my custom link text for function foo `.
+  See :c:type:`my custom link text for struct bar `.
 
-Questo produce dei collegamenti migliori, ed è in linea con il modo in cui
-kernel-doc gestisce i riferimenti.
-
-Per maggiori informazioni, siete pregati di consultare la documentazione
-del `dominio Sphinx per il C`_.
 
 Commenti per una documentazione generale
 
diff --git a/Documentation/translations/it_IT/doc-guide/sphinx.rst 
b/Documentation/translations/it_IT/doc-guide/sphinx.rst
index f1ad4504b734..090d2949d345 100644
--- a/Documentation/translations/it_IT/doc-guide/sphinx.rst
+++ b/Documentation/translations/it_IT/doc-guide/sphinx.rst
@@ -364,6 +364,26 @@ Che verrà rappresentata nel seguente modo:
 
 - column 3
 
+Riferimenti inc

Re: [PATCH v2] doc:it_IT: align Italian documentation

[Federico Vaga]

On 2020-11-13 22:53, Jonathan Corbet wrote:

On Fri, 13 Nov 2020 14:36:38 +0100
Federico Vaga  wrote:


Translation for the following patches

commit 905705a8fd43 ("docs: programming-languages: refresh blurb on 
clang support")
commit 5ff4aa70bf34 ("docs: submitting-patches: use :doc: for 
references")
commit 030f066f677f ("docs: submitting-patches: describe preserving 
review/test tags")
commit 68e4cd17e218 ("docs: deprecated.rst: Add zero-length and 
one-element arrays")
commit 5429ef62bcf3 ("compiler/gcc: Raise minimum GCC version for 
kernel builds to 4.8")
commit 5b5bbb8cc51b ("docs: process: Add an example for creating a 
fixes tag")
commit 858e6845654d ("docs: dt: convert submitting-patches.txt to ReST 
format")

commit cca73e4946c4 ("docs: Correct the release date of 5.2 stable")
commit c170f2eb9648 ("docs: Document cross-referencing between 
documentation pages")
commit 7c8b9e3000f8 ("kernel-doc: Update "cross-referencing from rST" 
section to use automarkup")
commit 27def953b63b ("docs: deprecated.rst: Expand str*cpy() 
replacement notes")
commit 17dca0502314 ("docs: deprecated.rst: Update 
zero-length/one-element arrays section")

commit 3519c4d6e08e ("Documentation: add minimum clang/llvm version")
commit 0bddd227f3dc ("Documentation: update for gcc 4.9 requirement")
commit 9f364b605f34 ("submitting-patches.rst: presume git will be 
used")
commit 4ebdf7be21d6 ("Documentation/maintainer: rehome sign-off 
process")
commit 7433ff33e8ba ("Documentation/process: expand plain-text 
advice")

commit eb45fb2fb16d ("docs: process: Add cross-link to security-bugs")
commit bdc48fa11e46 ("checkpatch/coding-style: deprecate 80-column 
warning")
commit f67281a72b30 ("Documentation: process: step 2: Link to email 
list fixed")


Signed-off-by: Federico Vaga 


This doesn't apply to docs-next, not quite sure why.


I did the patch on top of the doc-next of 2 days ago. I will have a 
double check.
I have other patches for new translations (4) between doc-next and this 
patch. I will

try to apply it directly on doc-next.

Also...what changed with v2?  Please always include that information 
under

the "---" line.


A missing '_'. I had a pre-compiled documentation when I did the first 
build and I missed a warning.



Thanks,

jon


--
Federico Vaga
http://www.federicovaga.it/

[PATCH v2] doc:it_IT: align Italian documentation

[Federico Vaga]

Translation for the following patches

commit 905705a8fd43 ("docs: programming-languages: refresh blurb on clang 
support")
commit 5ff4aa70bf34 ("docs: submitting-patches: use :doc: for references")
commit 030f066f677f ("docs: submitting-patches: describe preserving review/test 
tags")
commit 68e4cd17e218 ("docs: deprecated.rst: Add zero-length and one-element 
arrays")
commit 5429ef62bcf3 ("compiler/gcc: Raise minimum GCC version for kernel builds 
to 4.8")
commit 5b5bbb8cc51b ("docs: process: Add an example for creating a fixes tag")
commit 858e6845654d ("docs: dt: convert submitting-patches.txt to ReST format")
commit cca73e4946c4 ("docs: Correct the release date of 5.2 stable")
commit c170f2eb9648 ("docs: Document cross-referencing between documentation 
pages")
commit 7c8b9e3000f8 ("kernel-doc: Update "cross-referencing from rST" section 
to use automarkup")
commit 27def953b63b ("docs: deprecated.rst: Expand str*cpy() replacement notes")
commit 17dca0502314 ("docs: deprecated.rst: Update zero-length/one-element 
arrays section")
commit 3519c4d6e08e ("Documentation: add minimum clang/llvm version")
commit 0bddd227f3dc ("Documentation: update for gcc 4.9 requirement")
commit 9f364b605f34 ("submitting-patches.rst: presume git will be used")
commit 4ebdf7be21d6 ("Documentation/maintainer: rehome sign-off process")
commit 7433ff33e8ba ("Documentation/process: expand plain-text advice")
commit eb45fb2fb16d ("docs: process: Add cross-link to security-bugs")
commit bdc48fa11e46 ("checkpatch/coding-style: deprecate 80-column warning")
commit f67281a72b30 ("Documentation: process: step 2: Link to email list fixed")

Signed-off-by: Federico Vaga 
---
 .../it_IT/doc-guide/kernel-doc.rst|  30 +-
 .../translations/it_IT/doc-guide/sphinx.rst   |  20 ++
 .../translations/it_IT/process/2.Process.rst  |   4 +-
 .../translations/it_IT/process/changes.rst|  18 +-
 .../it_IT/process/coding-style.rst|  26 +-
 .../translations/it_IT/process/deprecated.rst | 147 -
 .../it_IT/process/email-clients.rst   |   5 +
 .../it_IT/process/programming-language.rst|   8 +-
 .../it_IT/process/submitting-patches.rst  | 295 +-
 9 files changed, 292 insertions(+), 261 deletions(-)

diff --git a/Documentation/translations/it_IT/doc-guide/kernel-doc.rst 
b/Documentation/translations/it_IT/doc-guide/kernel-doc.rst
index 524ad86cadbb..009cdac014b6 100644
--- a/Documentation/translations/it_IT/doc-guide/kernel-doc.rst
+++ b/Documentation/translations/it_IT/doc-guide/kernel-doc.rst
@@ -419,26 +419,24 @@ del `dominio Sphinx per il C`_.
 Riferimenti usando reStructuredText
 ~~~
 
-Per fare riferimento a funzioni e tipi di dato definiti nei commenti kernel-doc
-all'interno dei documenti reStructuredText, utilizzate i riferimenti dal
-`dominio Sphinx per il C`_. Per esempio::
+Nei documenti reStructuredText non serve alcuna sintassi speciale per
+fare riferimento a funzioni e tipi definiti nei commenti
+kernel-doc. Sarà sufficiente terminare i nomi di funzione con ``()``,
+e scrivere ``struct``, ``union``, ``enum``, o ``typedef`` prima di un
+tipo. Per esempio::
 
-  See function :c:func:`foo` and struct/union/enum/typedef :c:type:`bar`.
+  See foo()
+  See struct foo.
+  See union bar.
+  See enum baz.
+  See typedef meh.
 
-Nonostante il riferimento ai tipi di dato funzioni col solo nome,
-ovvero senza specificare struct/union/enum/typedef, potreste preferire il
-seguente::
+Tuttavia, la personalizzazione dei collegamenti è possibile solo con
+la seguente sintassi::
 
-  See :c:type:`struct foo `.
-  See :c:type:`union bar `.
-  See :c:type:`enum baz `.
-  See :c:type:`typedef meh `.
+  See :c:func:`my custom link text for function foo `.
+  See :c:type:`my custom link text for struct bar `.
 
-Questo produce dei collegamenti migliori, ed è in linea con il modo in cui
-kernel-doc gestisce i riferimenti.
-
-Per maggiori informazioni, siete pregati di consultare la documentazione
-del `dominio Sphinx per il C`_.
 
 Commenti per una documentazione generale
 
diff --git a/Documentation/translations/it_IT/doc-guide/sphinx.rst 
b/Documentation/translations/it_IT/doc-guide/sphinx.rst
index f1ad4504b734..090d2949d345 100644
--- a/Documentation/translations/it_IT/doc-guide/sphinx.rst
+++ b/Documentation/translations/it_IT/doc-guide/sphinx.rst
@@ -364,6 +364,26 @@ Che verrà rappresentata nel seguente modo:
 
 - column 3
 
+Riferimenti incrociati
+--
+
+Per fare dei riferimenti incrociati da una pagina ad un'altra
+specificando il percorso a partire dalla cartella *Documentation*.
+Per esempio, se volete aggiungere un riferimento a questa pagina
+(l'estensione .rst è opzionale)::
+
+ 

[PATCH] doc:it_IT: align Italian documentation

[Federico Vaga]

Translation for the following patches

commit 905705a8fd43 ("docs: programming-languages: refresh blurb on clang 
support")
commit 5ff4aa70bf34 ("docs: submitting-patches: use :doc: for references")
commit 030f066f677f ("docs: submitting-patches: describe preserving review/test 
tags")
commit 68e4cd17e218 ("docs: deprecated.rst: Add zero-length and one-element 
arrays")
commit 5429ef62bcf3 ("compiler/gcc: Raise minimum GCC version for kernel builds 
to 4.8")
commit 5b5bbb8cc51b ("docs: process: Add an example for creating a fixes tag")
commit 858e6845654d ("docs: dt: convert submitting-patches.txt to ReST format")
commit cca73e4946c4 ("docs: Correct the release date of 5.2 stable")
commit c170f2eb9648 ("docs: Document cross-referencing between documentation 
pages")
commit 7c8b9e3000f8 ("kernel-doc: Update "cross-referencing from rST" section 
to use automarkup")
commit 27def953b63b ("docs: deprecated.rst: Expand str*cpy() replacement notes")
commit 17dca0502314 ("docs: deprecated.rst: Update zero-length/one-element 
arrays section")
commit 3519c4d6e08e ("Documentation: add minimum clang/llvm version")
commit 0bddd227f3dc ("Documentation: update for gcc 4.9 requirement")
commit 9f364b605f34 ("submitting-patches.rst: presume git will be used")
commit 4ebdf7be21d6 ("Documentation/maintainer: rehome sign-off process")
commit 7433ff33e8ba ("Documentation/process: expand plain-text advice")
commit eb45fb2fb16d ("docs: process: Add cross-link to security-bugs")
commit bdc48fa11e46 ("checkpatch/coding-style: deprecate 80-column warning")
commit f67281a72b30 ("Documentation: process: step 2: Link to email list fixed")

Signed-off-by: Federico Vaga 
---
 .../it_IT/doc-guide/kernel-doc.rst|  30 +-
 .../translations/it_IT/doc-guide/sphinx.rst   |  20 ++
 .../translations/it_IT/process/2.Process.rst  |   4 +-
 .../translations/it_IT/process/changes.rst|  18 +-
 .../it_IT/process/coding-style.rst|  26 +-
 .../translations/it_IT/process/deprecated.rst | 147 -
 .../it_IT/process/email-clients.rst   |   5 +
 .../it_IT/process/programming-language.rst|   8 +-
 .../it_IT/process/submitting-patches.rst  | 295 +-
 9 files changed, 292 insertions(+), 261 deletions(-)

diff --git a/Documentation/translations/it_IT/doc-guide/kernel-doc.rst 
b/Documentation/translations/it_IT/doc-guide/kernel-doc.rst
index 524ad86cadbb..009cdac014b6 100644
--- a/Documentation/translations/it_IT/doc-guide/kernel-doc.rst
+++ b/Documentation/translations/it_IT/doc-guide/kernel-doc.rst
@@ -419,26 +419,24 @@ del `dominio Sphinx per il C`_.
 Riferimenti usando reStructuredText
 ~~~
 
-Per fare riferimento a funzioni e tipi di dato definiti nei commenti kernel-doc
-all'interno dei documenti reStructuredText, utilizzate i riferimenti dal
-`dominio Sphinx per il C`_. Per esempio::
+Nei documenti reStructuredText non serve alcuna sintassi speciale per
+fare riferimento a funzioni e tipi definiti nei commenti
+kernel-doc. Sarà sufficiente terminare i nomi di funzione con ``()``,
+e scrivere ``struct``, ``union``, ``enum``, o ``typedef`` prima di un
+tipo. Per esempio::
 
-  See function :c:func:`foo` and struct/union/enum/typedef :c:type:`bar`.
+  See foo()
+  See struct foo.
+  See union bar.
+  See enum baz.
+  See typedef meh.
 
-Nonostante il riferimento ai tipi di dato funzioni col solo nome,
-ovvero senza specificare struct/union/enum/typedef, potreste preferire il
-seguente::
+Tuttavia, la personalizzazione dei collegamenti è possibile solo con
+la seguente sintassi::
 
-  See :c:type:`struct foo `.
-  See :c:type:`union bar `.
-  See :c:type:`enum baz `.
-  See :c:type:`typedef meh `.
+  See :c:func:`my custom link text for function foo `.
+  See :c:type:`my custom link text for struct bar `.
 
-Questo produce dei collegamenti migliori, ed è in linea con il modo in cui
-kernel-doc gestisce i riferimenti.
-
-Per maggiori informazioni, siete pregati di consultare la documentazione
-del `dominio Sphinx per il C`_.
 
 Commenti per una documentazione generale
 
diff --git a/Documentation/translations/it_IT/doc-guide/sphinx.rst 
b/Documentation/translations/it_IT/doc-guide/sphinx.rst
index f1ad4504b734..090d2949d345 100644
--- a/Documentation/translations/it_IT/doc-guide/sphinx.rst
+++ b/Documentation/translations/it_IT/doc-guide/sphinx.rst
@@ -364,6 +364,26 @@ Che verrà rappresentata nel seguente modo:
 
 - column 3
 
+Riferimenti incrociati
+--
+
+Per fare dei riferimenti incrociati da una pagina ad un'altra
+specificando il percorso a partire dalla cartella *Documentation*.
+Per esempio, se volete aggiungere un riferimento a questa pagina
+(l'estensione .rst è opzionale)::
+
+ 

Re: [PATCH v4 24/52] docs: it_IT: fix namespace collisions at locking.rst

[Federico Vaga]

On 2020-09-30 15:24, Mauro Carvalho Chehab wrote:

The C domain functions there collide with the English ones,
due to namespace collision, generating lots of warnings with
Sphinx 3.x:

./include/linux/mutex.h:121: WARNING: Duplicate C declaration, also
defined in 'translations/it_IT/kernel-hacking/locking'.
Declaration is 'mutex_init'.
./include/linux/mutex.h:152: WARNING: Duplicate C declaration, also
defined in 'translations/it_IT/kernel-hacking/locking'.
Declaration is 'mutex_is_locked'.
./include/linux/mutex.h:226: WARNING: Duplicate C declaration, also
defined in 'translations/it_IT/kernel-hacking/locking'.
Declaration is 'mutex_trylock_recursive'.
./kernel/locking/mutex.c:281: WARNING: Duplicate C declaration, also
defined in 'translations/it_IT/kernel-hacking/locking'.
Declaration is 'mutex_lock'.
...

Add a namespace tag there, in order to prevent that.

Signed-off-by: Mauro Carvalho Chehab 


Acked-by: Federico Vaga 



---
 Documentation/translations/it_IT/kernel-hacking/locking.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git
a/Documentation/translations/it_IT/kernel-hacking/locking.rst
b/Documentation/translations/it_IT/kernel-hacking/locking.rst
index 4615df5723fb..bf1acd6204ef 100644
--- a/Documentation/translations/it_IT/kernel-hacking/locking.rst
+++ b/Documentation/translations/it_IT/kernel-hacking/locking.rst
@@ -1,5 +1,7 @@
 .. include:: ../disclaimer-ita.rst

+.. c:namespace:: it_IT
+
 :Original: :ref:`Documentation/kernel-hacking/locking.rst
`
 :Translator: Federico Vaga 


--
Federico Vaga
http://www.federicovaga.it/

Re: [PATCH v4 46/52] docs: it_IT: hacking.rst: fix a typo on a markup

[Federico Vaga]

On 2020-09-30 15:25, Mauro Carvalho Chehab wrote:

There's a missing "`", causing this warning:
./Documentation/translations/it_IT/kernel-hacking/hacking.rst:404:
WARNING: Unparseable C cross-reference: 'cpu_to_be32p(), che prende un
puntatore\nad un tipo, e ritorna il valore convertito. L\'altra
variante per\nla famiglia di conversioni "in-situ", come
:c:func:`cpu_to_be32s'
Invalid C declaration: Expected end of definition. [error at 14]
  cpu_to_be32p(), che prende un puntatore
ad un tipo, e ritorna il valore convertito. L'altra variante per
la famiglia di conversioni "in-situ", come :c:func:`cpu_to_be32s
  --^

Signed-off-by: Mauro Carvalho Chehab 


Acked-by: Federico Vaga 


---
 Documentation/translations/it_IT/kernel-hacking/hacking.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git
a/Documentation/translations/it_IT/kernel-hacking/hacking.rst
b/Documentation/translations/it_IT/kernel-hacking/hacking.rst
index 6aab27a8d323..3d30b69f1ec1 100644
--- a/Documentation/translations/it_IT/kernel-hacking/hacking.rst
+++ b/Documentation/translations/it_IT/kernel-hacking/hacking.rst
@@ -402,7 +402,7 @@ il valore convertito. Tutte le varianti supportano
anche il processo inverso:
 :c:func:`be32_to_cpu()`, eccetera.

 Queste funzioni hanno principalmente due varianti: la variante per
-puntatori, come :c:func:`cpu_to_be32p(), che prende un puntatore
+puntatori, come :c:func:`cpu_to_be32p()`, che prende un puntatore
 ad un tipo, e ritorna il valore convertito. L'altra variante per
 la famiglia di conversioni "in-situ", come :c:func:`cpu_to_be32s()`,
 che convertono il valore puntato da un puntatore, e ritornano void.


--
Federico Vaga
http://www.federicovaga.it/

Re: [PATCH] doc:it_IT: align Italian documentation

[Federico Vaga]

sure, no problem

On 2020-09-10 18:58, Jonathan Corbet wrote:

On Thu, 10 Sep 2020 00:38:39 +0200
Federico Vaga  wrote:


Translation for the following patches

commit 68e4cd17e218 ("docs: deprecated.rst: Add zero-length and 
one-element arrays")
commit 5429ef62bcf3 ("compiler/gcc: Raise minimum GCC version for 
kernel builds to 4.8")
commit 5b5bbb8cc51b ("docs: process: Add an example for creating a 
fixes tag")
commit 858e6845654d ("docs: dt: convert submitting-patches.txt to ReST 
format")
commit bdc48fa11e46 ("checkpatch/coding-style: deprecate 80-column 
warning")

commit cca73e4946c4 ("docs: Correct the release date of 5.2 stable")

Signed-off-by: Federico Vaga 


So this doesn't apply to current docs-next...care to respin?

Thanks,

jon


--
Federico Vaga
http://www.federicovaga.it/

[PATCH] doc: fix file references

[Federico Vaga]

Patch generated with

./scripts/documentation-file-ref-check --fix

Signed-off-by: Federico Vaga 
---
 .../bindings/display/tilcdc/tilcdc.txt   |  2 +-
 .../devicetree/bindings/media/i2c/tvp5150.txt|  2 +-
 .../bindings/soc/qcom/qcom,smd-rpm.yaml  |  2 +-
 Documentation/scheduler/sched-capacity.rst   |  2 +-
 Documentation/scheduler/sched-energy.rst |  2 +-
 Documentation/trace/kprobetrace.rst  |  2 +-
 MAINTAINERS  | 16 
 drivers/net/appletalk/Kconfig|  2 +-
 drivers/net/hamradio/scc.c   |  2 +-
 .../bindings/net/wireless/siliabs,wfx.txt|  2 +-
 init/Kconfig |  2 +-
 mm/Kconfig   |  2 +-
 mm/nommu.c   |  2 +-
 samples/kprobes/kprobe_example.c |  2 +-
 samples/kprobes/kretprobe_example.c  |  2 +-
 scripts/coccinelle/api/device_attr_show.cocci|  2 +-
 16 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt 
b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
index 8b2a71395647..3e64075ac7ec 100644
--- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
@@ -37,7 +37,7 @@ Optional nodes:
supports a single port with a single endpoint.
 
  - See also Documentation/devicetree/bindings/display/tilcdc/panel.txt and
-   Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt for 
connecting
+   Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml for 
connecting
tfp410 DVI encoder or lcd panel to lcdc
 
 [1] There is an errata about AM335x color wiring. For 16-bit color mode
diff --git a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt 
b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
index 6c88ce858d08..719b2995dc17 100644
--- a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
+++ b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
@@ -56,7 +56,7 @@ Optional Connector Properties:
   instead of using the autodetection mechnism. Please look at
   [1] for more information.
 
-[1] 
Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt.
+[1] 
Documentation/devicetree/bindings/display/connector/analog-tv-connector.yaml.
 
 Example - three input sources:
 #include 
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml 
b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
index 468d658ce3e7..2684f22a1d85 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
@@ -20,7 +20,7 @@ description: |
   present and this subnode may contain children that designate regulator
   resources.
 
-  Refer to 
Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
+  Refer to 
Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml
   for information on the regulator subnodes that can exist under the
   rpm_requests.
 
diff --git a/Documentation/scheduler/sched-capacity.rst 
b/Documentation/scheduler/sched-capacity.rst
index 00bf0d011e2a..9b7cbe43b2d1 100644
--- a/Documentation/scheduler/sched-capacity.rst
+++ b/Documentation/scheduler/sched-capacity.rst
@@ -365,7 +365,7 @@ giving it a high uclamp.min value.
 .. note::
 
   Wakeup CPU selection in CFS can be eclipsed by Energy Aware Scheduling
-  (EAS), which is described in Documentation/scheduling/sched-energy.rst.
+  (EAS), which is described in Documentation/scheduler/sched-energy.rst.
 
 5.1.3 Load balancing
 
diff --git a/Documentation/scheduler/sched-energy.rst 
b/Documentation/scheduler/sched-energy.rst
index 78f850778982..001e09c95e1d 100644
--- a/Documentation/scheduler/sched-energy.rst
+++ b/Documentation/scheduler/sched-energy.rst
@@ -331,7 +331,7 @@ asymmetric CPU topologies for now. This requirement is 
checked at run-time by
 looking for the presence of the SD_ASYM_CPUCAPACITY flag when the scheduling
 domains are built.
 
-See Documentation/sched/sched-capacity.rst for requirements to be met for this
+See Documentation/scheduler/sched-capacity.rst for requirements to be met for 
this
 flag to be set in the sched_domain hierarchy.
 
 Please note that EAS is not fundamentally incompatible with SMP, but no
diff --git a/Documentation/trace/kprobetrace.rst 
b/Documentation/trace/kprobetrace.rst
index c1709165c553..10850a9e9af3 100644
--- a/Documentation/trace/kprobetrace.rst
+++ b/Documentation/trace/kprobetrace.rst
@@ -40,7 +40,7 @@ Synopsis of kprobe_events
  MEMADDR   : Address where the probe is inserted.
  MAXACTIVE : Maximum number of instances of the specified function that
  can be probed simultaneously, or 0 for the default value

[PATCH] doc:it_IT: align Italian documentation

[Federico Vaga]

Translation for the following patches

commit 68e4cd17e218 ("docs: deprecated.rst: Add zero-length and one-element 
arrays")
commit 5429ef62bcf3 ("compiler/gcc: Raise minimum GCC version for kernel builds 
to 4.8")
commit 5b5bbb8cc51b ("docs: process: Add an example for creating a fixes tag")
commit 858e6845654d ("docs: dt: convert submitting-patches.txt to ReST format")
commit bdc48fa11e46 ("checkpatch/coding-style: deprecate 80-column warning")
commit cca73e4946c4 ("docs: Correct the release date of 5.2 stable")

Signed-off-by: Federico Vaga 
---
 .../translations/it_IT/process/2.Process.rst  |   2 +-
 .../translations/it_IT/process/changes.rst|   2 +-
 .../it_IT/process/coding-style.rst|  26 ++--
 .../translations/it_IT/process/deprecated.rst | 128 ++
 .../it_IT/process/submitting-patches.rst  |   7 +-
 5 files changed, 152 insertions(+), 13 deletions(-)

diff --git a/Documentation/translations/it_IT/process/2.Process.rst 
b/Documentation/translations/it_IT/process/2.Process.rst
index 30dc172f06b0..220248127285 100644
--- a/Documentation/translations/it_IT/process/2.Process.rst
+++ b/Documentation/translations/it_IT/process/2.Process.rst
@@ -123,7 +123,7 @@ iniziale, i kernel ricevono aggiornamenti per più di un 
ciclo di sviluppo.
 Quindi, per esempio, la storia del kernel 5.2 appare così (anno 2019):
 
==  ===
-   15 settembre5.2 rilascio stabile FIXME settembre è sbagliato
+7 luglio   5.2 rilascio stabile
14 luglio   5.2.1
21 luglio   5.2.2
26 luglio   5.2.3
diff --git a/Documentation/translations/it_IT/process/changes.rst 
b/Documentation/translations/it_IT/process/changes.rst
index 02da4408983d..3310d788fca3 100644
--- a/Documentation/translations/it_IT/process/changes.rst
+++ b/Documentation/translations/it_IT/process/changes.rst
@@ -32,7 +32,7 @@ PC Card, per esempio, probabilmente non dovreste preoccuparvi 
di pcmciautils.
 == =  

 Programma   Versione minima   Comando per verificare la 
versione
 == =  

-GNU C  4.6gcc --version
+GNU C  4.8gcc --version
 GNU make   3.81   make --version
 binutils   2.23   ld -v
 flex   2.5.35 flex --version
diff --git a/Documentation/translations/it_IT/process/coding-style.rst 
b/Documentation/translations/it_IT/process/coding-style.rst
index 6f4f85832dee..e188692deefe 100644
--- a/Documentation/translations/it_IT/process/coding-style.rst
+++ b/Documentation/translations/it_IT/process/coding-style.rst
@@ -92,16 +92,22 @@ delle righe.
 Lo stile del codice riguarda la leggibilità e la manutenibilità utilizzando
 strumenti comuni.
 
-Il limite delle righe è di 80 colonne e questo e un limite fortemente
-desiderato.
-
-Espressioni più lunghe di 80 colonne saranno spezzettate in pezzi più piccoli,
-a meno che eccedere le 80 colonne non aiuti ad aumentare la leggibilità senza
-nascondere informazioni.  I pezzi derivati sono sostanzialmente più corti degli
-originali e vengono posizionati più a destra.  Lo stesso si applica, nei file
-d'intestazione, alle funzioni con una lista di argomenti molto lunga. Tuttavia,
-non spezzettate mai le stringhe visibili agli utenti come i messaggi di
-printk, questo perché inibireste la possibilità d'utilizzare grep per cercarle.
+Come limite di riga si preferiscono le 80 colonne.
+
+Espressioni più lunghe di 80 colonne dovrebbero essere spezzettate in
+pezzi più piccoli, a meno che eccedere le 80 colonne non aiuti ad
+aumentare la leggibilità senza nascondere informazioni.
+
+I nuovi pezzi derivati sono sostanzialmente più corti degli originali
+e vengono posizionati più a destra. Uno stile molto comune è quello di
+allineare i nuovi pezzi alla parentesi aperta di una funzione.
+
+Lo stesso si applica, nei file d'intestazione, alle funzioni con una
+lista di argomenti molto lunga.
+
+Tuttavia, non spezzettate mai le stringhe visibili agli utenti come i
+messaggi di printk, questo perché inibireste la possibilità
+d'utilizzare grep per cercarle.
 
 3) Posizionamento di parentesi graffe e spazi
 -
diff --git a/Documentation/translations/it_IT/process/deprecated.rst 
b/Documentation/translations/it_IT/process/deprecated.rst
index e108eaf82cf6..158a63d9f244 100644
--- a/Documentation/translations/it_IT/process/deprecated.rst
+++ b/Documentation/translations/it_IT/process/deprecated.rst
@@ -95,6 +95,11 @@ Invece, usate la seguente funzione::
 
header = kzalloc(struct_size(header, item, count), GFP_KERNEL);
 
+.. note:: Se per caso state usando struct_size() su una struttura dati che

Re: [PATCH 1/1] doc:it_IT: process: coding-style.rst: Correct __maybe_unused compiler label

[Federico Vaga]

Of course, you are right! Thanks

On 2020-07-15 14:23, Lee Jones wrote:

Flag is __maybe_unused, not __maybe_used.

Cc: Federico Vaga 
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
Cc: clang-built-li...@googlegroups.com
Signed-off-by: Lee Jones 
---
 Documentation/translations/it_IT/process/coding-style.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/translations/it_IT/process/coding-style.rst
b/Documentation/translations/it_IT/process/coding-style.rst
index 6f4f85832deea..a346f1f2ce21f 100644
--- a/Documentation/translations/it_IT/process/coding-style.rst
+++ b/Documentation/translations/it_IT/process/coding-style.rst
@@ -1097,7 +1097,7 @@ la direttiva condizionale su di esse.

 Se avete una variabile o funzione che potrebbe non essere usata in 
alcune
 configurazioni, e quindi il compilatore potrebbe avvisarvi circa la 
definizione
-inutilizzata, marcate questa definizione come __maybe_used piuttosto 
che
+inutilizzata, marcate questa definizione come __maybe_unused piuttosto 
che
 racchiuderla in una direttiva condizionale del preprocessore.  
(Comunque,

 se una variabile o funzione è *sempre* inutilizzata, rimuovetela).


--
Federico Vaga
http://www.federicovaga.it/

Re: DMA Engine: Transfer From Userspace

[Federico Vaga]

On Mon, Jun 22, 2020 at 02:01:12PM +0200, Thomas Ruf wrote:

On 22 June 2020 at 06:47 Vinod Koul  wrote:

On 21-06-20, 22:36, Federico Vaga wrote:
> On Sun, Jun 21, 2020 at 12:54:57PM +0530, Vinod Koul wrote:
> > On 19-06-20, 16:31, Dave Jiang wrote:
> > >
> > >
> > > On 6/19/2020 3:47 PM, Federico Vaga wrote:
> > > > Hello,
> > > >
> > > > is there the possibility of using a DMA engine channel from userspace?
> > > >
> > > > Something like:
> > > > - configure DMA using ioctl() (or whatever configuration mechanism)
> > > > - read() or write() to trigger the transfer
> > > >
> > >
> > > I may have supposedly promised Vinod to look into possibly providing
> > > something like this in the future. But I have not gotten around to do that
> > > yet. Currently, no such support.
> >
> > And I do still have serious reservations about this topic :) Opening up
> > userspace access to DMA does not sound very great from security point of
> > view.
>
> I was thinking about a dedicated module, and not something that the DMA engine
> offers directly. You load the module only if you need it (like the test 
module)

But loading that module would expose dma to userspace.
>
> > Federico, what use case do you have in mind?
>
> Userspace drivers

more the reason not do do so, why cant a kernel driver be added for your
usage?


by chance i have written a driver allowing dma from user space using a memcpy 
like interface ;-)
now i am trying to get this code upstream but was hit by the fact that DMA_SG 
is gone since Aug 2017 :-(


Not sure to get what you mean by "DMA_SG is gone". Can I have a reference?



just let me introduce myself and the project:
- coding in C since '91
- coding in C++ since '98
- a lot of stuff not relevant for this ;-)
- working as a freelancer since Nov '19
- implemented a "dma-sg-proxy" driver for my client in Mar/Apr '20 to copy 
camera frames from uncached memory to cached memory using a second dma on a Zynq platform
- last week we figured out that we can not upgrade from "Xilinx 2019.2" (kernel 4.19.x) 
to "2020.1" (kernel 5.4.x) because the DMA_SG interface is gone
- subscribed to dmaengine on friday, saw the start of this discussion on 
saturday
- talked to my client today if it is ok to try to revive DMA_SG and get our 
driver upstream to avoid such problems in future

here the struct for the ioctl:

typedef struct {
 unsigned int struct_size;
 const void *src_user_ptr;
 void *dst_user_ptr;
 unsigned long length;
 unsigned int timeout_in_ms;
} dma_sg_proxy_arg_t;


Yes, roughly this is what I was thinking about


best regards,
Thomas

Re: DMA Engine: Transfer From Userspace

[Federico Vaga]

On Sat, Jun 20, 2020 at 12:47:16AM +0200, Federico Vaga wrote:

Hello,

is there the possibility of using a DMA engine channel from userspace?

Something like:
- configure DMA using ioctl() (or whatever configuration mechanism)
- read() or write() to trigger the transfer


Let me add one more question related to my case. The dmatest module does not
perform tests on SLAVEs. why?

Thanks



--
Federico Vaga [CERN BE-CO-HT]

Re: DMA Engine: Transfer From Userspace

[Federico Vaga]

On Mon, Jun 22, 2020 at 10:17:33AM +0530, Vinod Koul wrote:

On 21-06-20, 22:36, Federico Vaga wrote:

On Sun, Jun 21, 2020 at 12:54:57PM +0530, Vinod Koul wrote:
> On 19-06-20, 16:31, Dave Jiang wrote:
> >
> >
> > On 6/19/2020 3:47 PM, Federico Vaga wrote:
> > > Hello,
> > >
> > > is there the possibility of using a DMA engine channel from userspace?
> > >
> > > Something like:
> > > - configure DMA using ioctl() (or whatever configuration mechanism)
> > > - read() or write() to trigger the transfer
> > >
> >
> > I may have supposedly promised Vinod to look into possibly providing
> > something like this in the future. But I have not gotten around to do that
> > yet. Currently, no such support.
>
> And I do still have serious reservations about this topic :) Opening up
> userspace access to DMA does not sound very great from security point of
> view.

I was thinking about a dedicated module, and not something that the DMA engine
offers directly. You load the module only if you need it (like the test module)


But loading that module would expose dma to userspace.


Of course, but users *should* know what they are doing ... right? ^_^'



> Federico, what use case do you have in mind?

Userspace drivers


more the reason not do do so, why cant a kernel driver be added for your
usage?


Yes of course, I was just wandering if there was a kernel API.


--
~Vinod

Re: DMA Engine: Transfer From Userspace

[Federico Vaga]

On Sun, Jun 21, 2020 at 10:45:04PM +0200, Richard Weinberger wrote:

On Sun, Jun 21, 2020 at 10:37 PM Federico Vaga  wrote:

>Federico, what use case do you have in mind?

Userspace drivers


Is using vfio an option?


I do not know the subsystem. Could be, thanks for the suggestion I will have
a look.


--
Thanks,
//richard

Re: DMA Engine: Transfer From Userspace

[Federico Vaga]

On Sun, Jun 21, 2020 at 12:54:57PM +0530, Vinod Koul wrote:

On 19-06-20, 16:31, Dave Jiang wrote:



On 6/19/2020 3:47 PM, Federico Vaga wrote:
> Hello,
>
> is there the possibility of using a DMA engine channel from userspace?
>
> Something like:
> - configure DMA using ioctl() (or whatever configuration mechanism)
> - read() or write() to trigger the transfer
>

I may have supposedly promised Vinod to look into possibly providing
something like this in the future. But I have not gotten around to do that
yet. Currently, no such support.


And I do still have serious reservations about this topic :) Opening up
userspace access to DMA does not sound very great from security point of
view.


I was thinking about a dedicated module, and not something that the DMA engine
offers directly. You load the module only if you need it (like the test module)


Federico, what use case do you have in mind?


Userspace drivers


We should keep in mind dmaengine is an in-kernel interface providing
services to various subsystems, so you go thru the respective subsystem
kernel interface (network, display, spi, audio etc..) which would in
turn use dmaengine.

--
~Vinod

DMA Engine: Transfer From Userspace

[Federico Vaga]

Hello,

is there the possibility of using a DMA engine channel from userspace?

Something like:
- configure DMA using ioctl() (or whatever configuration mechanism)
- read() or write() to trigger the transfer

-- 
Federico Vaga [CERN BE-CO-HT]

Re: [PATCH 22/29] docs: it_IT: add two missing references

[Federico Vaga]

It is already fixed by https://lkml.org/lkml/2020/5/31/260

On Monday, June 15, 2020 8:47:01 AM CEST Mauro Carvalho Chehab wrote:
> there are missing references causing Sphinx warnings:
> 
> Documentation/translations/it_IT/process/submitting-patches.rst:384:
> WARNING: undefined label: it_email_clients (if the link has no caption the
> label must precede a section header)
> Documentation/translations/it_IT/process/submitting-patches.rst:384:
> WARNING: undefined label: it_email_clients (if the link has no caption the
> label must precede a section header)
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/translations/it_IT/process/management-style.rst   | 2 ++
>  Documentation/translations/it_IT/process/submitting-patches.rst | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/Documentation/translations/it_IT/process/management-style.rst
> b/Documentation/translations/it_IT/process/management-style.rst index
> 76ed074082ea..f7acee105c05 100644
> --- a/Documentation/translations/it_IT/process/management-style.rst
> +++ b/Documentation/translations/it_IT/process/management-style.rst
> @@ -1,5 +1,7 @@
>  .. include:: ../disclaimer-ita.rst
> 
> +.. _it_managementstyle:
> +
> 
>  :Original: :doc:`../../../process/management-style`
>  :Translator: Alessia Mantegazza 
> 
> diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst
> b/Documentation/translations/it_IT/process/submitting-patches.rst index
> 7c23c08e4401..94c816b4e8f8 100644
> --- a/Documentation/translations/it_IT/process/submitting-patches.rst
> +++ b/Documentation/translations/it_IT/process/submitting-patches.rst
> @@ -1,3 +1,5 @@
> +.. _it_email_clients:
> +
>  .. include:: ../disclaimer-ita.rst
> 
>  :Original: :ref:`Documentation/process/submitting-patches.rst
>  :`

[PATCH] doc:it_IT: add symbol-namespace translation

[Federico Vaga]

- add complete translation of symbol-namespaces.rst
- fix references to this page within the italian translation
- add document to main indexes

Signed-off-by: Federico Vaga 
---
 .../translations/it_IT/core-api/index.rst |  18 ++
 .../it_IT/core-api/symbol-namespaces.rst  | 166 ++
 Documentation/translations/it_IT/index.rst|   5 +-
 .../it_IT/kernel-hacking/hacking.rst  |   4 +-
 4 files changed, 189 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/translations/it_IT/core-api/index.rst
 create mode 100644 
Documentation/translations/it_IT/core-api/symbol-namespaces.rst

diff --git a/Documentation/translations/it_IT/core-api/index.rst 
b/Documentation/translations/it_IT/core-api/index.rst
new file mode 100644
index ..cc4c4328ad03
--- /dev/null
+++ b/Documentation/translations/it_IT/core-api/index.rst
@@ -0,0 +1,18 @@
+===
+Documentazione dell'API di base
+===
+
+Utilità di base
+===
+
+.. toctree::
+   :maxdepth: 1
+
+   symbol-namespaces
+
+.. only:: subproject and html
+
+   Indices
+   ===
+
+   * :ref:`genindex`
diff --git a/Documentation/translations/it_IT/core-api/symbol-namespaces.rst 
b/Documentation/translations/it_IT/core-api/symbol-namespaces.rst
new file mode 100644
index ..aa851a57a4b0
--- /dev/null
+++ b/Documentation/translations/it_IT/core-api/symbol-namespaces.rst
@@ -0,0 +1,166 @@
+.. include:: ../disclaimer-ita.rst
+
+:Original: :doc:`../../../core-api/symbol-namespaces`
+:Translator: Federico Vaga 
+
+===
+Spazio dei nomi dei simboli
+===
+
+Questo documento descrive come usare lo spazio dei nomi dei simboli
+per strutturare quello che viene esportato internamente al kernel
+grazie alle macro della famiglia EXPORT_SYMBOL().
+
+1. Introduzione
+===
+
+Lo spazio dei nomi dei simboli è stato introdotto come mezzo per strutturare
+l'API esposta internamente al kernel. Permette ai manutentori di un
+sottosistema di organizzare i simboli esportati in diversi spazi di
+nomi. Questo meccanismo è utile per la documentazione (pensate ad
+esempio allo spazio dei nomi SUBSYSTEM_DEBUG) così come per limitare
+la disponibilità di un gruppo di simboli in altre parti del kernel. Ad
+oggi, i moduli che usano simboli esportati da uno spazio di nomi
+devono prima importare detto spazio. Altrimenti il kernel, a seconda
+della configurazione, potrebbe rifiutare di caricare il modulo o
+avvisare l'utente di un'importazione mancante.
+
+2. Come definire uno spazio dei nomi dei simboli
+
+
+I simboli possono essere esportati in spazi dei nomi usando diversi
+meccanismi.  Tutti questi meccanismi cambiano il modo in cui
+EXPORT_SYMBOL e simili vengono guidati verso la creazione di voci in ksymtab.
+
+2.1 Usare le macro EXPORT_SYMBOL
+
+
+In aggiunta alle macro EXPORT_SYMBOL() e EXPORT_SYMBOL_GPL(), che permettono
+di esportare simboli del kernel nella rispettiva tabella, ci sono
+varianti che permettono di esportare simboli all'interno di uno spazio dei
+nomi: EXPORT_SYMBOL_NS() ed EXPORT_SYMBOL_NS_GPL(). Queste macro richiedono un
+argomento aggiuntivo: lo spazio dei nomi.
+Tenete presente che per via dell'espansione delle macro questo argomento deve
+essere un simbolo di preprocessore. Per esempio per esportare il
+simbolo `usb_stor_suspend` nello spazio dei nomi `USB_STORAGE` usate::
+
+   EXPORT_SYMBOL_NS(usb_stor_suspend, USB_STORAGE);
+
+Di conseguenza, nella tabella dei simboli del kernel ci sarà una voce
+rappresentata dalla struttura `kernel_symbol` che avrà il campo
+`namespace` (spazio dei nomi) impostato. Un simbolo esportato senza uno spazio
+dei nomi avrà questo campo impostato a `NULL`. Non esiste uno spazio dei nomi
+di base. Il programma `modpost` e il codice in kernel/module.c usano lo spazio
+dei nomi, rispettivamente, durante la compilazione e durante il caricamento
+di un modulo.
+
+2.2 Usare il simbolo di preprocessore DEFAULT_SYMBOL_NAMESPACE
+==
+
+Definire lo spazio dei nomi per tutti i simboli di un sottosistema può essere
+logorante e di difficile manutenzione. Perciò è stato fornito un simbolo
+di preprocessore di base (DEFAULT_SYMBOL_NAMESPACE), che, se impostato,
+diventa lo spazio dei simboli di base per tutti gli usi di EXPORT_SYMBOL()
+ed EXPORT_SYMBOL_GPL() che non specificano esplicitamente uno spazio dei nomi.
+
+Ci sono molti modi per specificare questo simbolo di preprocessore e il loro
+uso dipende dalle preferenze del manutentore di un sottosistema. La prima
+possibilità è quella di definire il simbolo nel `Makefile` del sottosistema.
+Per esempio per esportare tutti i simboli definiti in usb-common nello spazio
+dei nomi USB_COMMON, si può aggiungere la seguente linea in
+drivers/usb/common/Makefile::
+
+   ccflags-y

Re: [PATCH] Replace HTTP links with HTTPS ones: Documentation/translations/it_IT

[Federico Vaga]

On Tuesday, June 9, 2020 10:12:41 PM CEST Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
> 
> Deterministic algorithm:
> For each file:
>   For each line:
> If doesn't contain `\bxmlns\b`:
>   For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
>   Replace HTTP with HTTPS.
> 
> Signed-off-by: Alexander A. Klimov 
> ---
>  .../translations/it_IT/admin-guide/README.rst  |  2 +-
>  .../translations/it_IT/doc-guide/parse-headers.rst |  2 +-
>  .../translations/it_IT/doc-guide/sphinx.rst| 10 +-
>  .../translations/it_IT/process/2.Process.rst   | 12 ++--
>  .../translations/it_IT/process/3.Early-stage.rst   |  2 +-
>  .../translations/it_IT/process/4.Coding.rst|  4 ++--
>  .../it_IT/process/7.AdvancedTopics.rst |  8 
>  .../translations/it_IT/process/8.Conclusion.rst| 14 +++---
>  .../translations/it_IT/process/adding-syscalls.rst |  4 ++--
>  .../translations/it_IT/process/changes.rst |  6 +++---
>  .../translations/it_IT/process/clang-format.rst|  2 +-
>  .../translations/it_IT/process/coding-style.rst|  2 +-
>  Documentation/translations/it_IT/process/howto.rst |  2 +-
>  .../it_IT/process/maintainer-pgp-guide.rst |  2 +-
>  .../it_IT/process/submitting-patches.rst   |  4 ++--
>  .../it_IT/process/volatile-considered-harmful.rst  |  4 ++--
>  16 files changed, 40 insertions(+), 40 deletions(-)
> 


> diff --git a/Documentation/translations/it_IT/doc-guide/sphinx.rst
> b/Documentation/translations/it_IT/doc-guide/sphinx.rst index
> f1ad4504b734..0aaeb0297661 100644
> --- a/Documentation/translations/it_IT/doc-guide/sphinx.rst
> +++ b/Documentation/translations/it_IT/doc-guide/sphinx.rst
> @@ -14,7 +14,7 @@ Per generare la documentazione in HTML o PDF, usate
> comandi ``make htmldocs`` o ``make pdfdocs``. La documentazione così
> generata sarà disponibile nella cartella ``Documentation/output``.
> 
> -.. _Sphinx: http://www.sphinx-doc.org/
> +.. _Sphinx: https://www.sphinx-doc.org/
>  .. _reStructuredText: http://docutils.sourceforge.net/rst.html

It is not part of the deterministic algorithm but you may consider this as 
well

-.. _reStructuredText: http://docutils.sourceforge.net/rst.html
+.. _reStructuredText: https://docutils.sourceforge.io/rst.html

Re: [PATCH] docs: it_IT: address invalid reference warnings

[Federico Vaga]

I re-read the documents with the full context.

Moving to the directive :doc: for only those two references (like I was 
arguing in the previous email) will make the document inconsistent.
So, the patch is fine for me as it is.

I will finish and push the translation for ../core-api/symbol-namespace.rst
and move the link again

On Tuesday, June 2, 2020 10:37:21 AM CEST Federico Vaga wrote:
> On Sunday, May 31, 2020 8:56:18 PM CEST Lukas Bulwahn wrote:
> > Documentation generation warns:
> >   it_IT/kernel-hacking/hacking.rst:
> > WARNING: unknown document: ../core-api/symbol/namespaces
> >   
> >   it_IT/process/5.Posting.rst:
> > WARNING: undefined label: it_email_clients
> >   
> >   it_IT/process/submitting-patches.rst:
> > WARNING: undefined label: it_email_clients
> >   
> >   it_IT/process/howto.rst:
> >  WARNING: undefined label: it_managementstyle
> > 
> > Refer to English documentation, as Italian translation does not exist,
> > and
> 
> The file exists! On my disk :D
> My mistake, I have an almost done translation for that and of course I do
> not see the warning.
> 
> > add labels for Italian process documents to resolve label references.
> 
> I think we have agreed to not use labels but instead to sue the directive
> 
> :doc: instead. This fix should happen in the document that points here. When
> :I
> posted the new translations I removed those labels but forgot to fix:
> it_IT/process/5.Posting.rst, it_IT/process/submitting-patches.rst and it_IT/
> process/howto.rst
> 
> :doc:`../process/email-clients`
> :doc:`../process/management-style`
> 
> I should be more meticulous and regenerate the full translation every time.
> Lesson learned. Sorry for that and thanks
> 
> > Signed-off-by: Lukas Bulwahn 
> > ---
> > Jonathan, please pick this quick fix of warnings.
> > 
> > applies on doc-next and next-20200529
> > 
> >  Documentation/translations/it_IT/kernel-hacking/hacking.rst   | 4 ++--
> >  Documentation/translations/it_IT/process/email-clients.rst| 2 ++
> >  Documentation/translations/it_IT/process/management-style.rst | 2 ++
> >  3 files changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/translations/it_IT/kernel-hacking/hacking.rst
> > b/Documentation/translations/it_IT/kernel-hacking/hacking.rst index
> > 6aab27a8d323..e9a2e92134f0 100644
> > --- a/Documentation/translations/it_IT/kernel-hacking/hacking.rst
> > +++ b/Documentation/translations/it_IT/kernel-hacking/hacking.rst
> > @@ -634,7 +634,7 @@ Definita in ``include/linux/export.h``
> > 
> >  Questa è una variate di `EXPORT_SYMBOL()` che permette di specificare uno
> >  spazio dei nomi. Lo spazio dei nomi è documentato in
> > 
> > -:doc:`../core-api/symbol-namespaces`
> > +:doc:`../../../core-api/symbol-namespaces`
> > 
> >  :c:func:`EXPORT_SYMBOL_NS_GPL()`
> >  
> >  
> > 
> > @@ -643,7 +643,7 @@ Definita in ``include/linux/export.h``
> > 
> >  Questa è una variate di `EXPORT_SYMBOL_GPL()` che permette di specificare
> > 
> > uno spazio dei nomi. Lo spazio dei nomi è documentato in
> > -:doc:`../core-api/symbol-namespaces`
> > +:doc:`../../../core-api/symbol-namespaces`
> > 
> >  Procedure e convenzioni
> >  ===
> > 
> > diff --git a/Documentation/translations/it_IT/process/email-clients.rst
> > b/Documentation/translations/it_IT/process/email-clients.rst index
> > 89abf6d325f2..66d3d65776f7 100644
> > --- a/Documentation/translations/it_IT/process/email-clients.rst
> > +++ b/Documentation/translations/it_IT/process/email-clients.rst
> > @@ -3,6 +3,8 @@
> > 
> >  :Original: :doc:`../../../process/email-clients`
> >  :Translator: Alessia Mantegazza 
> > 
> > +.. _it_email_clients:
> > +
> > 
> >  Informazioni sui programmi di posta elettronica per Linux
> >  =
> > 
> > diff --git a/Documentation/translations/it_IT/process/management-style.rst
> > b/Documentation/translations/it_IT/process/management-style.rst index
> > c709285138a7..76ed074082ea 100644
> > --- a/Documentation/translations/it_IT/process/management-style.rst
> > +++ b/Documentation/translations/it_IT/process/management-style.rst
> > @@ -3,6 +3,8 @@
> > 
> >  :Original: :doc:`../../../process/management-style`
> >  :Translator: Alessia Mantegazza 
> > 
> > +.. _it_managementstyle:
> > +
> > 
> >  Il modello di gestione del kernel Linux
> >  ===

Re: [PATCH] docs: it_IT: address invalid reference warnings

[Federico Vaga]

On Sunday, May 31, 2020 8:56:18 PM CEST Lukas Bulwahn wrote:
> Documentation generation warns:
> 
>   it_IT/kernel-hacking/hacking.rst:
> WARNING: unknown document: ../core-api/symbol/namespaces
> 
>   it_IT/process/5.Posting.rst:
> WARNING: undefined label: it_email_clients
> 
>   it_IT/process/submitting-patches.rst:
> WARNING: undefined label: it_email_clients
> 
>   it_IT/process/howto.rst:
>  WARNING: undefined label: it_managementstyle
> 
> Refer to English documentation, as Italian translation does not exist,
> and 

The file exists! On my disk :D
My mistake, I have an almost done translation for that and of course I do not 
see the warning.

> add labels for Italian process documents to resolve label references.

I think we have agreed to not use labels but instead to sue the directive 
:doc: instead. This fix should happen in the document that points here. When I 
posted the new translations I removed those labels but forgot to fix:
it_IT/process/5.Posting.rst, it_IT/process/submitting-patches.rst and it_IT/
process/howto.rst

:doc:`../process/email-clients`
:doc:`../process/management-style`

I should be more meticulous and regenerate the full translation every time. 
Lesson learned. Sorry for that and thanks

> 
> Signed-off-by: Lukas Bulwahn 
> ---
> Jonathan, please pick this quick fix of warnings.
> 
> applies on doc-next and next-20200529
> 
>  Documentation/translations/it_IT/kernel-hacking/hacking.rst   | 4 ++--
>  Documentation/translations/it_IT/process/email-clients.rst| 2 ++
>  Documentation/translations/it_IT/process/management-style.rst | 2 ++
>  3 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/translations/it_IT/kernel-hacking/hacking.rst
> b/Documentation/translations/it_IT/kernel-hacking/hacking.rst index
> 6aab27a8d323..e9a2e92134f0 100644
> --- a/Documentation/translations/it_IT/kernel-hacking/hacking.rst
> +++ b/Documentation/translations/it_IT/kernel-hacking/hacking.rst
> @@ -634,7 +634,7 @@ Definita in ``include/linux/export.h``
> 
>  Questa è una variate di `EXPORT_SYMBOL()` che permette di specificare uno
>  spazio dei nomi. Lo spazio dei nomi è documentato in
> -:doc:`../core-api/symbol-namespaces`
> +:doc:`../../../core-api/symbol-namespaces`
> 
>  :c:func:`EXPORT_SYMBOL_NS_GPL()`
> 
>  
> @@ -643,7 +643,7 @@ Definita in ``include/linux/export.h``
> 
>  Questa è una variate di `EXPORT_SYMBOL_GPL()` che permette di specificare
> uno spazio dei nomi. Lo spazio dei nomi è documentato in
> -:doc:`../core-api/symbol-namespaces`
> +:doc:`../../../core-api/symbol-namespaces`
> 
>  Procedure e convenzioni
>  ===
> diff --git a/Documentation/translations/it_IT/process/email-clients.rst
> b/Documentation/translations/it_IT/process/email-clients.rst index
> 89abf6d325f2..66d3d65776f7 100644
> --- a/Documentation/translations/it_IT/process/email-clients.rst
> +++ b/Documentation/translations/it_IT/process/email-clients.rst
> @@ -3,6 +3,8 @@
> 
>  :Original: :doc:`../../../process/email-clients`
>  :Translator: Alessia Mantegazza 
> 
> +.. _it_email_clients:
> +
>  Informazioni sui programmi di posta elettronica per Linux
>  =
> 
> diff --git a/Documentation/translations/it_IT/process/management-style.rst
> b/Documentation/translations/it_IT/process/management-style.rst index
> c709285138a7..76ed074082ea 100644
> --- a/Documentation/translations/it_IT/process/management-style.rst
> +++ b/Documentation/translations/it_IT/process/management-style.rst
> @@ -3,6 +3,8 @@
> 
>  :Original: :doc:`../../../process/management-style`
>  :Translator: Alessia Mantegazza 
> 
> +.. _it_managementstyle:
> +
>  Il modello di gestione del kernel Linux
>  ===

[PATCH] doc:it_IT: align Italian translation

[Federico Vaga]

Translation for the following patches:

commit c4f4af4094d6 ("docs: Add documentation for Symbol Namespaces")
commit 36bc683dde0a ("kernel-doc: rename the kernel-doc directive 'functions' 
to 'identifiers'")
commit a035d552a93b ("Makefile: Globally enable fall-through warning")
commit b9918bdcac1f ("Documentation/process: Add fallthrough pseudo-keyword")
commit 58ad30cf91f0 ("docs: fix reference to core-api/namespaces.rst")
commit fb0e0ffe7fc8 ("Documentation: bring process docs up to date")
commit 7af51678b6d3 ("docs: deprecated.rst: Add BUG()-family")
commit 7929b9836ed0 ("docs: Remove :c:func: from process/deprecated.rst")
commit 76136e028d3b ("docs: deprecated.rst: Clean up fall-through details")
commit d8401f504b49 ("docs: deprecated.rst: Add %p to the list")
commit b1735296cef9 ("docs: locking: Drop :c:func: throughout")
commit 6adb7755996f ("docs: locking: Add 'need' to hardirq section")

Signed-off-by: Federico Vaga 
---
 .../it_IT/doc-guide/kernel-doc.rst|  25 ++-
 .../it_IT/kernel-hacking/hacking.rst  |  18 ++
 .../it_IT/kernel-hacking/locking.rst  | 172 +-
 .../translations/it_IT/process/2.Process.rst  |  95 +-
 .../it_IT/process/coding-style.rst|   6 +-
 .../translations/it_IT/process/deprecated.rst | 130 +++--
 6 files changed, 287 insertions(+), 159 deletions(-)

diff --git a/Documentation/translations/it_IT/doc-guide/kernel-doc.rst 
b/Documentation/translations/it_IT/doc-guide/kernel-doc.rst
index a4ecd8f27631..524ad86cadbb 100644
--- a/Documentation/translations/it_IT/doc-guide/kernel-doc.rst
+++ b/Documentation/translations/it_IT/doc-guide/kernel-doc.rst
@@ -515,6 +515,22 @@ internal: *[source-pattern ...]*
 .. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c
:internal:
 
+identifiers: *[ function/type ...]*
+  Include la documentazione per ogni *function* e *type*  in *source*.
+  Se non vengono esplicitamente specificate le funzioni da includere, allora
+  verranno incluse tutte quelle disponibili in *source*.
+
+  Esempi::
+
+.. kernel-doc:: lib/bitmap.c
+   :identifiers: bitmap_parselist bitmap_parselist_user
+
+.. kernel-doc:: lib/idr.c
+   :identifiers:
+
+functions: *[ function ...]*
+  Questo è uno pseudonimo, deprecato, per la direttiva 'identifiers'.
+
 doc: *title*
   Include la documentazione del paragrafo ``DOC:`` identificato dal titolo
   (*title*) all'interno del file sorgente (*source*). Gli spazi in *title* sono
@@ -528,15 +544,6 @@ doc: *title*
 .. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c
:doc: High Definition Audio over HDMI and Display Port
 
-functions: *function* *[...]*
-  Dal file sorgente (*source*) include la documentazione per le funzioni
-  elencate (*function*).
-
-  Esempio::
-
-.. kernel-doc:: lib/bitmap.c
-   :functions: bitmap_parselist bitmap_parselist_user
-
 Senza alcuna opzione, la direttiva kernel-doc include tutti i commenti di
 documentazione presenti nel file sorgente (*source*).
 
diff --git a/Documentation/translations/it_IT/kernel-hacking/hacking.rst 
b/Documentation/translations/it_IT/kernel-hacking/hacking.rst
index 24c592852bf1..6aab27a8d323 100644
--- a/Documentation/translations/it_IT/kernel-hacking/hacking.rst
+++ b/Documentation/translations/it_IT/kernel-hacking/hacking.rst
@@ -627,6 +627,24 @@ Alcuni manutentori e sviluppatori potrebbero comunque 
richiedere
 :c:func:`EXPORT_SYMBOL_GPL()` quando si aggiungono nuove funzionalità o
 interfacce.
 
+:c:func:`EXPORT_SYMBOL_NS()`
+
+
+Definita in ``include/linux/export.h``
+
+Questa è una variate di `EXPORT_SYMBOL()` che permette di specificare uno
+spazio dei nomi. Lo spazio dei nomi è documentato in
+:doc:`../core-api/symbol-namespaces`
+
+:c:func:`EXPORT_SYMBOL_NS_GPL()`
+
+
+Definita in ``include/linux/export.h``
+
+Questa è una variate di `EXPORT_SYMBOL_GPL()` che permette di specificare uno
+spazio dei nomi. Lo spazio dei nomi è documentato in
+:doc:`../core-api/symbol-namespaces`
+
 Procedure e convenzioni
 ===
 
diff --git a/Documentation/translations/it_IT/kernel-hacking/locking.rst 
b/Documentation/translations/it_IT/kernel-hacking/locking.rst
index b9a6be4b8499..4615df5723fb 100644
--- a/Documentation/translations/it_IT/kernel-hacking/locking.rst
+++ b/Documentation/translations/it_IT/kernel-hacking/locking.rst
@@ -159,17 +159,17 @@ Sincronizzazione in contesto utente
 Se avete una struttura dati che verrà utilizzata solo dal contesto utente,
 allora, per proteggerla, potete utilizzare un semplice mutex
 (``include/linux/mutex.h``). Questo è il caso più semplice: inizializzate il
-mutex; invocate :c:func:`mutex_lock_interruptible()` per trattenerlo e
-:c:func:`mutex_unlock()` per rilasciarlo. C'è anche :c:func:`mutex_lock()`
+mutex; invocate mutex_lock_inte

Re: [PATCH] doc:lock: remove reference to clever use of read-write lock

[Federico Vaga]

On Monday, September 2, 2019 8:10:10 PM CEST Ingo Molnar wrote:
> * Federico Vaga  wrote:
> > On Saturday, August 31, 2019 4:43:44 PM CEST Jonathan Corbet wrote:
> > > On Sat, 31 Aug 2019 15:41:16 +0200
> > > 
> > > Federico Vaga  wrote:
> > > >  several CPU's and you want to use spinlocks you can potentially use
> > > > 
> > > > -cheaper versions of the spinlocks. IFF you know that the spinlocks
> > > > are
> > > > +cheaper versions of the spinlocks. If you know that the spinlocks are
> > > > 
> > > >  never used in interrupt handlers, you can use the non-irq versions::
> > > I suspect that was not actually a typo; "iff" is a way for the
> > > mathematically inclined to say "if and only if".
> > > 
> > > jon
> > 
> > I learned something new today :)
> > 
> > I am not used to the mathematical English jargon. It make sense, but then
> > I
> > would replace it with "If and only if": for clarity.
> 
> While it's used in a number of places and it's pretty common wording
> overall in the literature, I agree that we should probably change this in
> locking API user facing documentation.

I would say not only in locking/. The argument is valid for the entire 
Documentation/. I wait for Jon's opinion before proceeding.

> If you change it, please do it in both places it's used.
> 
> Thanks,
> 
>   Ingo

[PATCH] i2c: ocores: use request_any_context_irq() to register IRQ handler

[Federico Vaga]

The i2c-ocores device is an HDL component that get instantiated in FPGA.
The software stack used to drive an FPGA can be very different, and the
i2c-ocore ip-core must work in different context. With respect to this
patch the IRQ controller behind this device, and its driver, can have
different implementations (nested threads). For this reason, it is safer
to use `request_any_context_irq()` to avoid errors at probe time.

Signed-off-by: Federico Vaga 
---
 drivers/i2c/busses/i2c-ocores.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 4117f1abc7c6..ca8b3ecfa93d 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -703,8 +703,9 @@ static int ocores_i2c_probe(struct platform_device *pdev)
}
 
if (ocores_algorithm.master_xfer != ocores_xfer_polling) {
-   ret = devm_request_irq(>dev, irq, ocores_isr, 0,
-  pdev->name, i2c);
+   ret = devm_request_any_context_irq(>dev, irq,
+  ocores_isr, 0,
+  pdev->name, i2c);
if (ret) {
dev_err(>dev, "Cannot claim IRQ\n");
goto err_clk;
-- 
2.15.0

Re: [PATCH] MAINTAINERS: Remove FMC subsystem

[Federico Vaga]

On Tuesday, August 13, 2019 8:15:47 AM CEST Denis Efremov wrote:
> Cleanup MAINTAINERS from FMC record since the subsystem was removed.
> 
> Cc: Linus Walleij 
> Cc: Federico Vaga 
> Cc: Pat Riehecky 
> Fixes: 6a80b30086b8 ("fmc: Delete the FMC subsystem")
> Signed-off-by: Denis Efremov 

Reviewed-by: Federico Vaga 

[PATCH] doc:it_IT: align translation to mainline

[Federico Vaga]

The patch translates the following patches in Italian:

1fb12b35e5ff kbuild: Raise the minimum required binutils version to 2.21
9c3c0c204814 isdn: remove isdn4linux

Signed-off-by: Federico Vaga 
---
 .../translations/it_IT/process/changes.rst| 22 ---
 1 file changed, 4 insertions(+), 18 deletions(-)

diff --git a/Documentation/translations/it_IT/process/changes.rst 
b/Documentation/translations/it_IT/process/changes.rst
index d0874327f301..94a6499742ac 100644
--- a/Documentation/translations/it_IT/process/changes.rst
+++ b/Documentation/translations/it_IT/process/changes.rst
@@ -26,16 +26,15 @@ Prima di pensare d'avere trovato un baco, aggiornate i 
seguenti programmi
 usando, il comando indicato dovrebbe dirvelo.
 
 Questa lista presume che abbiate già un kernel Linux funzionante.  In aggiunta,
-non tutti gli strumenti sono necessari ovunque; ovviamente, se non avete un
-modem ISDN, per esempio, probabilmente non dovreste preoccuparvi di
-isdn4k-utils.
+non tutti gli strumenti sono necessari ovunque; ovviamente, se non avete una
+PC Card, per esempio, probabilmente non dovreste preoccuparvi di pcmciautils.
 
 == =  

 Programma   Versione minima   Comando per verificare la 
versione
 == =  

 GNU C  4.6gcc --version
 GNU make   3.81   make --version
-binutils   2.20   ld -v
+binutils   2.21   ld -v
 flex   2.5.35 flex --version
 bison  2.0bison --version
 util-linux 2.10o  fdformat --version
@@ -49,7 +48,6 @@ btrfs-progs0.18   btrfsck
 pcmciautils004pccardctl -V
 quota-tools3.09   quota -V
 PPP2.4.0  pppd --version
-isdn4k-utils   3.1pre1isdnctrl 2>&1|grep version
 nfs-utils  1.0.5  showmount --version
 procps 3.2.0  ps --version
 oprofile   0.9oprofiled --version
@@ -81,10 +79,7 @@ Per compilare il kernel vi servirà GNU make 3.81 o 
successivo.
 Binutils
 
 
-Il sistema di compilazione, dalla versione 4.13,  per la produzione dei passi
-intermedi, si è convertito all'uso di *thin archive* (`ar T`) piuttosto che
-all'uso del *linking* incrementale (`ld -r`). Questo richiede binutils 2.20 o
-successivo.
+Per generare il kernel è necessario avere Binutils 2.21 o superiore.
 
 pkg-config
 --
@@ -286,11 +281,6 @@ col seguente comando::
 
   mknod /dev/ppp c 108 0
 
-Isdn4k-utils
-
-
-Per via della modifica del campo per il numero di telefono, il pacchetto
-isdn4k-utils dev'essere ricompilato o (preferibilmente) aggiornato.
 
 NFS-utils
 -
@@ -456,10 +446,6 @@ PPP
 
 - <ftp://ftp.samba.org/pub/ppp/>
 
-Isdn4k-utils
-
-
-- <ftp://ftp.isdn4linux.de/pub/isdn4linux/utils/>
 
 NFS-utils
 -
-- 
2.21.0

[PATCH 1/2] doc:it_IT: align translation to mainline

[Federico Vaga]

The patch translates the following patches in Italian:

d9d7c0c497b8 docs: Note that :c:func: should no longer be used
83e8b971f81c sphinx.rst: Add note about code snippets embedded in the text
cca5e0b8a430 Documentation: PGP: update for newer HW devices

Signed-off-by: Federico Vaga 
---
 .../translations/it_IT/doc-guide/sphinx.rst   | 17 +++--
 .../it_IT/process/maintainer-pgp-guide.rst| 25 ---
 2 files changed, 26 insertions(+), 16 deletions(-)

diff --git a/Documentation/translations/it_IT/doc-guide/sphinx.rst 
b/Documentation/translations/it_IT/doc-guide/sphinx.rst
index 1739cba8863e..d9ee4b1f098f 100644
--- a/Documentation/translations/it_IT/doc-guide/sphinx.rst
+++ b/Documentation/translations/it_IT/doc-guide/sphinx.rst
@@ -243,7 +243,8 @@ del kernel:
   esempio, casi d'uso, eccetera): utilizzate ``::`` quando non è necessario
   evidenziare la sintassi, specialmente per piccoli frammenti; invece,
   utilizzate ``.. code-block:: `` per blocchi di più lunghi che
-  potranno beneficiare dell'avere la sintassi evidenziata.
+  potranno beneficiare dell'avere la sintassi evidenziata. Per un breve pezzo
+  di codice da inserire nel testo, usate \`\`.
 
 
 Il dominio C
@@ -267,12 +268,14 @@ molto comune come ``open`` o ``ioctl``:
 
 Il nome della funzione (per esempio ioctl) rimane nel testo ma il nome del suo
 riferimento cambia da ``ioctl`` a ``VIDIOC_LOG_STATUS``. Anche la voce
-nell'indice cambia in ``VIDIOC_LOG_STATUS`` e si potrà quindi fare riferimento
-a questa funzione scrivendo:
-
-.. code-block:: rst
-
- :c:func:`VIDIOC_LOG_STATUS`
+nell'indice cambia in ``VIDIOC_LOG_STATUS``.
+
+Notate che per una funzione non c'è bisogno di usare ``c:func:`` per generarne
+i riferimenti nella documentazione. Grazie a qualche magica estensione a
+Sphinx, il sistema di generazione della documentazione trasformerà
+automaticamente un riferimento ad una ``funzione()`` in un riferimento
+incrociato quando questa ha una voce nell'indice.  Se trovate degli usi di
+``c:func:`` nella documentazione del kernel, sentitevi liberi di rimuoverli.
 
 
 Tabelle a liste
diff --git a/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst 
b/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst
index 276db0e37f43..118fb4153e8f 100644
--- a/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst
+++ b/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst
@@ -248,7 +248,10 @@ possano ricevere la vostra nuova sottochiave::
 kernel.
 
 Se per qualche ragione preferite rimanere con sottochiavi RSA, nel comando
-precedente, sostituite "ed25519" con "rsa2048".
+precedente, sostituite "ed25519" con "rsa2048". In aggiunta, se avete
+intenzione di usare un dispositivo hardware che non supporta le chiavi
+ED25519 ECC, come la Nitrokey Pro o la Yubikey, allora dovreste usare
+"nistp256" al posto di "ed25519".
 
 Copia di riserva della chiave primaria per gestire il recupero da disastro
 --
@@ -449,23 +452,27 @@ implementi le funzionalità delle smartcard.  Sul mercato 
ci sono diverse
 soluzioni disponibili:
 
 - `Nitrokey Start`_: è Open hardware e Free Software, è basata sul progetto
-  `GnuK`_ della FSIJ. Ha il supporto per chiavi ECC, ma meno funzionalità di
-  sicurezza (come la resistenza alla manomissione o alcuni attacchi ad un
-  canale laterale).
+  `GnuK`_ della FSIJ. Questo è uno dei pochi dispositivi a supportare le chiavi
+  ECC ED25519, ma offre meno funzionalità di sicurezza (come la resistenza
+  alla manomissione o alcuni attacchi ad un canale laterale).
 - `Nitrokey Pro`_: è simile alla Nitrokey Start, ma è più resistente alla
-  manomissione e offre più funzionalità di sicurezza, ma l'ECC.
-- `Yubikey 4`_: l'hardware e il software sono proprietari, ma è più economica
+  manomissione e offre più funzionalità di sicurezza. La Pro 2 supporta la
+  crittografia ECC (NISTP).
+- `Yubikey 5`_: l'hardware e il software sono proprietari, ma è più economica
   della  Nitrokey Pro ed è venduta anche con porta USB-C il che è utile con i
   computer portatili più recenti. In aggiunta, offre altre funzionalità di
-  sicurezza come FIDO, U2F, ma non l'ECC
+  sicurezza come FIDO, U2F, e ora supporta anche le chiavi ECC (NISTP)
 
 `Su LWN c'è una buona recensione`_ dei modelli elencati qui sopra e altri.
+La scelta dipenderà dal costo, dalla disponibilità nella vostra area
+geografica e vostre considerazioni sull'hardware aperto/proprietario.
+
 Se volete usare chiavi ECC, la vostra migliore scelta sul mercato è la
 Nitrokey Start.
 
 .. _`Nitrokey Start`: https://shop.nitrokey.com/shop/product/nitrokey-start-6
-.. _`Nitrokey Pro`: https://shop.nitrokey.com/shop/product/nitrokey-pro-3
-.. _`Yubikey 4`: https://www.yubico.com/product/yubikey-4-series/
+.. _`Nitrokey Pro 2`: https://shop.nitrok

[PATCH] doc:it_IT: translations in process/

[Federico Vaga]

This patch add translations for:

- programming-languages
- kernel-docs (It is better to not translate this since English is
a requirement to get something useful out of it)

Signed-off-by: Federico Vaga 
---
 .../translations/it_IT/process/index.rst  |  1 +
 .../it_IT/process/kernel-docs.rst | 11 ++--
 .../it_IT/process/programming-language.rst| 51 +++
 3 files changed, 60 insertions(+), 3 deletions(-)
 create mode 100644 
Documentation/translations/it_IT/process/programming-language.rst

diff --git a/Documentation/translations/it_IT/process/index.rst 
b/Documentation/translations/it_IT/process/index.rst
index 2eda85d5cd1e..012de0f3154a 100644
--- a/Documentation/translations/it_IT/process/index.rst
+++ b/Documentation/translations/it_IT/process/index.rst
@@ -27,6 +27,7 @@ Di seguito le guide che ogni sviluppatore dovrebbe leggere.
code-of-conduct
development-process
submitting-patches
+   programming-language
coding-style
maintainer-pgp-guide
email-clients
diff --git a/Documentation/translations/it_IT/process/kernel-docs.rst 
b/Documentation/translations/it_IT/process/kernel-docs.rst
index 7bd70d661737..38e0a955121a 100644
--- a/Documentation/translations/it_IT/process/kernel-docs.rst
+++ b/Documentation/translations/it_IT/process/kernel-docs.rst
@@ -1,6 +1,7 @@
 .. include:: ../disclaimer-ita.rst
 
 :Original: :ref:`Documentation/process/kernel-docs.rst `
+:Translator: Federico Vaga 
 
 
 .. _it_kernel_docs:
@@ -8,6 +9,10 @@
 Indice di documenti per le persone interessate a capire e/o scrivere per il 
kernel Linux
 

 
-.. warning::
-
-TODO ancora da tradurre
+.. note::
+   Questo documento contiene riferimenti a documenti in lingua inglese; inoltre
+   utilizza dai campi *ReStructuredText* di supporto alla ricerca e che per
+   questo motivo è meglio non tradurre al fine di garantirne un corretto
+   utilizzo.
+   Per questi motivi il documento non verrà tradotto. Per favore fate
+   riferimento al documento originale in lingua inglese.
diff --git a/Documentation/translations/it_IT/process/programming-language.rst 
b/Documentation/translations/it_IT/process/programming-language.rst
new file mode 100644
index ..f4b006395849
--- /dev/null
+++ b/Documentation/translations/it_IT/process/programming-language.rst
@@ -0,0 +1,51 @@
+.. include:: ../disclaimer-ita.rst
+
+:Original: :ref:`Documentation/process/programming-language.rst 
`
+:Translator: Federico Vaga 
+
+.. _it_programming_language:
+
+Linguaggio di programmazione
+
+
+Il kernel è scritto nel linguaggio di programmazione C [c-language]_.
+Più precisamente, il kernel viene compilato con ``gcc`` [gcc]_ usando
+l'opzione ``-std=gnu89`` [gcc-c-dialect-options]_: il dialetto GNU
+dello standard ISO C90 (con l'aggiunta di alcune funzionalità da C99)
+
+Questo dialetto contiene diverse estensioni al linguaggio [gnu-extensions]_,
+e molte di queste vengono usate sistematicamente dal kernel.
+
+Il kernel offre un certo livello di supporto per la compilazione con ``clang``
+[clang]_ e ``icc`` [icc]_ su diverse architetture, tuttavia in questo momento
+il supporto non è completo e richiede delle patch aggiuntive.
+
+Attributi
+-
+
+Una delle estensioni più comuni e usate nel kernel sono gli attributi
+[gcc-attribute-syntax]_. Gli attributi permettono di aggiungere una semantica,
+definita dell'implementazione, alle entità del linguaggio (come le variabili,
+le funzioni o i tipi) senza dover fare importanti modifiche sintattiche al
+linguaggio stesso (come l'aggiunta di nuove parole chiave) [n2049]_.
+
+In alcuni casi, gli attributi sono opzionali (ovvero un compilatore che non
+dovesse supportarli dovrebbe produrre comunque codice corretto, anche se
+più lento o che non esegue controlli aggiuntivi durante la compilazione).
+
+Il kernel definisce alcune pseudo parole chiave (per esempio ``__pure``)
+in alternativa alla sintassi GNU per gli attributi (per esempio
+``__attribute__((__pure__))``) allo scopo di mostrare quali funzionalità si
+possono usare e/o per accorciare il codice.
+
+Per maggiori informazioni consultate il file d'intestazione
+``include/linux/compiler_attributes.h``.
+
+.. [c-language] http://www.open-std.org/jtc1/sc22/wg14/www/standards
+.. [gcc] https://gcc.gnu.org
+.. [clang] https://clang.llvm.org
+.. [icc] https://software.intel.com/en-us/c-compilers
+.. [gcc-c-dialect-options] 
https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html
+.. [gnu-extensions] https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html
+.. [gcc-attribute-syntax] 
https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html
+.. [n2049] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2049.pdf
-- 
2.21.0

Re: [PATCH] fmc: Delete the FMC subsystem

[Federico Vaga]

Well I do not know if it make sense to make it stronger with:

Signed-off-by: Federico Vaga 

As you want

On Monday, June 10, 2019 4:18:09 PM CEST Linus Walleij wrote:
> The FMC subsystem was created in 2012 with the ambition to
> drive development of drivers for this hardware upstream.
> 
> The current implementation has architectural flaws and would
> need to be revamped using real hardware to something that can
> reuse existing kernel abstractions in the subsystems for e.g.
> I2C, FPGA and GPIO.
> 
> We have concluded that for the mainline kernel it will be
> better to delete the subsystem and start over with a clean
> slate when/if an active maintainer steps up.
> 
> For details see:
> https://lkml.org/lkml/2018/10/29/534
> 
> Suggested-by: Federico Vaga 
> Cc: Federico Vaga 
> Cc: Pat Riehecky 
> Cc: Alessandro Rubini 
> Signed-off-by: Linus Walleij 
> ---
> If people are happy with this, I will queue the removal
> in the GPIO kernel tree.
> ---
>  Documentation/fmc/API.txt  |  47 ---
>  Documentation/fmc/FMC-and-SDB.txt  |  88 --
>  Documentation/fmc/carrier.txt  | 311 
>  Documentation/fmc/fmc-chardev.txt  |  64 
>  Documentation/fmc/fmc-fakedev.txt  |  36 ---
>  Documentation/fmc/fmc-trivial.txt  |  17 --
>  Documentation/fmc/fmc-write-eeprom.txt |  98 ---
>  Documentation/fmc/identifiers.txt  | 168 ---
>  Documentation/fmc/mezzanine.txt| 123 
>  Documentation/fmc/parameters.txt   |  56 
>  drivers/fmc/Kconfig|  51 
>  drivers/fmc/Makefile   |  15 -
>  drivers/fmc/fmc-chardev.c  | 200 -
>  drivers/fmc/fmc-core.c | 389 -
>  drivers/fmc/fmc-debug.c| 173 ---
>  drivers/fmc/fmc-dump.c |  59 
>  drivers/fmc/fmc-fakedev.c  | 355 --
>  drivers/fmc/fmc-match.c| 114 
>  drivers/fmc/fmc-private.h  |   9 -
>  drivers/fmc/fmc-sdb.c  | 220 --
>  drivers/fmc/fmc-trivial.c  | 102 ---
>  drivers/fmc/fmc-write-eeprom.c | 176 ---
>  drivers/fmc/fru-parse.c|  81 -
>  include/linux/fmc-sdb.h|  39 ---
>  include/linux/fmc.h| 272 -
>  25 files changed, 3263 deletions(-)
>  delete mode 100644 Documentation/fmc/API.txt
>  delete mode 100644 Documentation/fmc/FMC-and-SDB.txt
>  delete mode 100644 Documentation/fmc/carrier.txt
>  delete mode 100644 Documentation/fmc/fmc-chardev.txt
>  delete mode 100644 Documentation/fmc/fmc-fakedev.txt
>  delete mode 100644 Documentation/fmc/fmc-trivial.txt
>  delete mode 100644 Documentation/fmc/fmc-write-eeprom.txt
>  delete mode 100644 Documentation/fmc/identifiers.txt
>  delete mode 100644 Documentation/fmc/mezzanine.txt
>  delete mode 100644 Documentation/fmc/parameters.txt
>  delete mode 100644 drivers/fmc/Kconfig
>  delete mode 100644 drivers/fmc/Makefile
>  delete mode 100644 drivers/fmc/fmc-chardev.c
>  delete mode 100644 drivers/fmc/fmc-core.c
>  delete mode 100644 drivers/fmc/fmc-debug.c
>  delete mode 100644 drivers/fmc/fmc-dump.c
>  delete mode 100644 drivers/fmc/fmc-fakedev.c
>  delete mode 100644 drivers/fmc/fmc-match.c
>  delete mode 100644 drivers/fmc/fmc-private.h
>  delete mode 100644 drivers/fmc/fmc-sdb.c
>  delete mode 100644 drivers/fmc/fmc-trivial.c
>  delete mode 100644 drivers/fmc/fmc-write-eeprom.c
>  delete mode 100644 drivers/fmc/fru-parse.c
>  delete mode 100644 include/linux/fmc-sdb.h
>  delete mode 100644 include/linux/fmc.h
> 
> diff --git a/Documentation/fmc/API.txt b/Documentation/fmc/API.txt
> deleted file mode 100644
> index 06b06b92c794..
> diff --git a/Documentation/fmc/FMC-and-SDB.txt
> b/Documentation/fmc/FMC-and-SDB.txt deleted file mode 100644
> index fa14e0b24521..
> diff --git a/Documentation/fmc/carrier.txt b/Documentation/fmc/carrier.txt
> deleted file mode 100644
> index 5e4f1dd3e98b..
> diff --git a/Documentation/fmc/fmc-chardev.txt
> b/Documentation/fmc/fmc-chardev.txt deleted file mode 100644
> index d9ccb278e597..
> diff --git a/Documentation/fmc/fmc-fakedev.txt
> b/Documentation/fmc/fmc-fakedev.txt deleted file mode 100644
> index e85b74a4ae30..
> diff --git a/Documentation/fmc/fmc-trivial.txt
> b/Documentation/fmc/fmc-trivial.txt deleted file mode 100644
> index d1910bc67159..
> diff --git a/Documentation/fmc/fmc-write-eeprom.txt
> b/Documentation/fmc/fmc-write-eeprom.txt deleted file mode 100644
> index e0a9712156aa..
> 

Re: [PATCH v2 11/22] docs: it: license-rules.rst: get rid of warnings

[Federico Vaga]

On Tuesday, June 4, 2019 4:17:45 PM CEST Mauro Carvalho Chehab wrote:
> There's a wrong identation on a code block, and it tries to use
> a reference that was not defined at the Italian translation.
> 
> Documentation/translations/it_IT/process/license-rules.rst:329: WARNING:
> Literal block expected; none found.
> Documentation/translations/it_IT/process/license-rules.rst:332: WARNING:
> Unexpected indentation.
> Documentation/translations/it_IT/process/license-rules.rst:339: WARNING:
> Block quote ends without a blank line; unexpected unindent.
> Documentation/translations/it_IT/process/license-rules.rst:341: WARNING:
> Unexpected indentation.
> Documentation/translations/it_IT/process/license-rules.rst:305: WARNING:
> Unknown target name: "metatags".
> 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Federico Vaga 

> ---
>  .../it_IT/process/license-rules.rst   | 28 +--
>  1 file changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/Documentation/translations/it_IT/process/license-rules.rst
> b/Documentation/translations/it_IT/process/license-rules.rst index
> f058e06996dc..4cd87a3a7bf9 100644
> --- a/Documentation/translations/it_IT/process/license-rules.rst
> +++ b/Documentation/translations/it_IT/process/license-rules.rst
> @@ -303,7 +303,7 @@ essere categorizzate in:
>   LICENSES/dual
> 
> I file in questa cartella contengono il testo completo della rispettiva
> -   licenza e i suoi `Metatags`_.  I nomi dei file sono identici agli
> +   licenza e i suoi `Metatag`_.  I nomi dei file sono identici agli
> identificatori di licenza SPDX che dovrebbero essere usati nei file
> sorgenti.
> 
> @@ -326,19 +326,19 @@ essere categorizzate in:
> 
> Esempio del formato del file::
> 
> -   Valid-License-Identifier: MPL-1.1
> -   SPDX-URL: https://spdx.org/licenses/MPL-1.1.html
> -   Usage-Guide:
> - Do NOT use. The MPL-1.1 is not GPL2 compatible. It may only be used
> for - dual-licensed files where the other license is GPL2 compatible. -
> If you end up using this it MUST be used together with a GPL2
> compatible - license using "OR".
> - To use the Mozilla Public License version 1.1 put the following SPDX
> - tag/value pair into a comment according to the placement guidelines in
> - the licensing rules documentation:
> -   SPDX-License-Identifier: MPL-1.1
> -   License-Text:
> - Full license text
> +Valid-License-Identifier: MPL-1.1
> +SPDX-URL: https://spdx.org/licenses/MPL-1.1.html
> +Usage-Guide:
> +  Do NOT use. The MPL-1.1 is not GPL2 compatible. It may only be used
> for +  dual-licensed files where the other license is GPL2 compatible.
> +  If you end up using this it MUST be used together with a GPL2
> compatible +  license using "OR".
> +  To use the Mozilla Public License version 1.1 put the following SPDX
> +  tag/value pair into a comment according to the placement guidelines
> in +  the licensing rules documentation:
> +SPDX-License-Identifier: MPL-1.1
> +License-Text:
> +  Full license text

Re: [PATCH 15/22] docs: it: license-rules.rst: get rid of warnings

[Federico Vaga]

On Thursday, May 30, 2019 1:23:46 AM CEST Mauro Carvalho Chehab wrote:
> There's a wrong identation on a code block, and it tries to use
> a reference that was not defined at the Italian translation.
> 
> Documentation/translations/it_IT/process/license-rules.rst:329: WARNING:
> Literal block expected; none found.
> Documentation/translations/it_IT/process/license-rules.rst:332: WARNING:
> Unexpected indentation.
> Documentation/translations/it_IT/process/license-rules.rst:339: WARNING:
> Block quote ends without a blank line; unexpected unindent.
> Documentation/translations/it_IT/process/license-rules.rst:341: WARNING:
> Unexpected indentation.
> Documentation/translations/it_IT/process/license-rules.rst:305: WARNING:
> Unknown target name: "metatags".
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  .../it_IT/process/license-rules.rst   | 28 +--
>  1 file changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/Documentation/translations/it_IT/process/license-rules.rst
> b/Documentation/translations/it_IT/process/license-rules.rst index
> f058e06996dc..06abeb7dd307 100644
> --- a/Documentation/translations/it_IT/process/license-rules.rst
> +++ b/Documentation/translations/it_IT/process/license-rules.rst
> @@ -303,7 +303,7 @@ essere categorizzate in:
>   LICENSES/dual
> 
> I file in questa cartella contengono il testo completo della rispettiva
> -   licenza e i suoi `Metatags`_.  I nomi dei file sono identici agli
> +   licenza e i suoi `Metatags`.  I nomi dei file sono identici agli

Remove 's' instead of '_' and then the link is correct

`Metatag`_

> identificatori di licenza SPDX che dovrebbero essere usati nei file
> sorgenti.
> 
> @@ -326,19 +326,19 @@ essere categorizzate in:
> 
> Esempio del formato del file::
> 
> -   Valid-License-Identifier: MPL-1.1
> -   SPDX-URL: https://spdx.org/licenses/MPL-1.1.html
> -   Usage-Guide:
> - Do NOT use. The MPL-1.1 is not GPL2 compatible. It may only be used
> for - dual-licensed files where the other license is GPL2 compatible. -
> If you end up using this it MUST be used together with a GPL2
> compatible - license using "OR".
> - To use the Mozilla Public License version 1.1 put the following SPDX
> - tag/value pair into a comment according to the placement guidelines in
> - the licensing rules documentation:
> -   SPDX-License-Identifier: MPL-1.1
> -   License-Text:
> - Full license text
> +Valid-License-Identifier: MPL-1.1
> +SPDX-URL: https://spdx.org/licenses/MPL-1.1.html
> +Usage-Guide:
> +  Do NOT use. The MPL-1.1 is not GPL2 compatible. It may only be used
> for +  dual-licensed files where the other license is GPL2 compatible.
> +  If you end up using this it MUST be used together with a GPL2
> compatible +  license using "OR".
> +  To use the Mozilla Public License version 1.1 put the following SPDX
> +  tag/value pair into a comment according to the placement guidelines
> in +  the licensing rules documentation:
> +SPDX-License-Identifier: MPL-1.1
> +License-Text:
> +  Full license text

[PATCH] doc:it_IT: fix file references

[Federico Vaga]

Fix italian translation file references based on
`scripts/documentation-file-ref-check` output.

Signed-off-by: Federico Vaga 
---
 .../it_IT/admin-guide/kernel-parameters.rst  | 12 
 .../translations/it_IT/process/adding-syscalls.rst   |  2 +-
 .../translations/it_IT/process/coding-style.rst  |  2 +-
 Documentation/translations/it_IT/process/howto.rst   |  2 +-
 .../translations/it_IT/process/magic-number.rst  |  2 +-
 .../it_IT/process/stable-kernel-rules.rst|  4 ++--
 6 files changed, 18 insertions(+), 6 deletions(-)
 create mode 100644 
Documentation/translations/it_IT/admin-guide/kernel-parameters.rst

diff --git a/Documentation/translations/it_IT/admin-guide/kernel-parameters.rst 
b/Documentation/translations/it_IT/admin-guide/kernel-parameters.rst
new file mode 100644
index ..0e36d82a92be
--- /dev/null
+++ b/Documentation/translations/it_IT/admin-guide/kernel-parameters.rst
@@ -0,0 +1,12 @@
+.. include:: ../disclaimer-ita.rst
+
+:Original: :ref:`Documentation/admin-guide/kernel-parameters.rst 
`
+
+.. _it_kernelparameters:
+
+I parametri da linea di comando del kernel
+==
+
+.. warning::
+
+TODO ancora da tradurre
diff --git a/Documentation/translations/it_IT/process/adding-syscalls.rst 
b/Documentation/translations/it_IT/process/adding-syscalls.rst
index e0a64b0688a7..c3a3439595a6 100644
--- a/Documentation/translations/it_IT/process/adding-syscalls.rst
+++ b/Documentation/translations/it_IT/process/adding-syscalls.rst
@@ -39,7 +39,7 @@ vostra interfaccia.
un qualche modo opaca.
 
  - Se dovete esporre solo delle informazioni sul sistema, un nuovo nodo in
-   sysfs (vedere ``Documentation/translations/it_IT/filesystems/sysfs.txt``) o
+   sysfs (vedere ``Documentation/filesystems/sysfs.txt``) o
in procfs potrebbe essere sufficiente.  Tuttavia, l'accesso a questi
meccanismi richiede che il filesystem sia montato, il che potrebbe non
essere sempre vero (per esempio, in ambienti come namespace/sandbox/chroot).
diff --git a/Documentation/translations/it_IT/process/coding-style.rst 
b/Documentation/translations/it_IT/process/coding-style.rst
index 5ef534c95e69..a6559d25a23d 100644
--- a/Documentation/translations/it_IT/process/coding-style.rst
+++ b/Documentation/translations/it_IT/process/coding-style.rst
@@ -696,7 +696,7 @@ nella stringa di titolo::
...
 
 Per la documentazione completa sui file di configurazione, consultate
-il documento Documentation/translations/it_IT/kbuild/kconfig-language.txt
+il documento Documentation/kbuild/kconfig-language.txt
 
 
 11) Strutture dati
diff --git a/Documentation/translations/it_IT/process/howto.rst 
b/Documentation/translations/it_IT/process/howto.rst
index 9903ac7c566b..44e6077730e8 100644
--- a/Documentation/translations/it_IT/process/howto.rst
+++ b/Documentation/translations/it_IT/process/howto.rst
@@ -131,7 +131,7 @@ Di seguito una lista di file che sono presenti nei sorgente 
del kernel e che
"Linux kernel patch submission format"
http://linux.yyz.us/patch-format.html
 
-  :ref:`Documentation/process/translations/it_IT/stable-api-nonsense.rst 
`
+  :ref:`Documentation/translations/it_IT/process/stable-api-nonsense.rst 
`
 
 Questo file descrive la motivazioni sottostanti la conscia decisione di
 non avere un API stabile all'interno del kernel, incluso cose come:
diff --git a/Documentation/translations/it_IT/process/magic-number.rst 
b/Documentation/translations/it_IT/process/magic-number.rst
index 5281d53e57ee..ed1121d0ba84 100644
--- a/Documentation/translations/it_IT/process/magic-number.rst
+++ b/Documentation/translations/it_IT/process/magic-number.rst
@@ -1,6 +1,6 @@
 .. include:: ../disclaimer-ita.rst
 
-:Original: :ref:`Documentation/process/magic-numbers.rst `
+:Original: :ref:`Documentation/process/magic-number.rst `
 :Translator: Federico Vaga 
 
 .. _it_magicnumbers:
diff --git a/Documentation/translations/it_IT/process/stable-kernel-rules.rst 
b/Documentation/translations/it_IT/process/stable-kernel-rules.rst
index 48e88e5ad2c5..4f206cee31a7 100644
--- a/Documentation/translations/it_IT/process/stable-kernel-rules.rst
+++ b/Documentation/translations/it_IT/process/stable-kernel-rules.rst
@@ -33,7 +33,7 @@ Regole sul tipo di patch che vengono o non vengono accettate 
nei sorgenti
  - Non deve includere alcuna correzione "banale" (correzioni grammaticali,
pulizia dagli spazi bianchi, eccetera).
  - Deve rispettare le regole scritte in
-   :ref:`Documentation/translation/it_IT/process/submitting-patches.rst 
`
+   :ref:`Documentation/translations/it_IT/process/submitting-patches.rst 
`
  - Questa patch o una equivalente deve esistere già nei sorgenti principali di
Linux
 
@@ -43,7 +43,7 @@ Procedura per sottomettere patch per i sorgenti -stable
 
  - Se la patch contiene modifiche a dei file nelle cartelle net/ o drivers/net,
allora seguite le linee guida d

Re: Device Description for FPGA Components on x86 system

[Federico Vaga]

Hi Alan,

thanks for your answer

On Wednesday, April 10, 2019 4:21:09 PM CEST Alan Tull wrote:
> On Wed, Apr 10, 2019 at 7:50 AM Federico Vaga  wrote:
> 
> Hi Federico,
> 
> I wish I could point you to a complete solution, but there is a lot of
> work to be done in this area.  Most of what is in the kernel is a low
> level in-kernel API [4].  As you correctly state, the hardest part of
> this is doing the enumerating if you are on x86 and aren't using
> devicetree.
> 
> > Hi,
> > 
> > P.S. sorry if I'm too verbose, hopefully it is useful
> > 
> > thanks for the answer
> > 
> > On Wednesday, April 10, 2019 12:30:14 PM CEST Eric Schwarz wrote:
> > > Hi,
> > > 
> > > everything you want is already available and on the way to mainline
> > > concerning support for various FPGA loading modes or available for
> > > checkout from a git repository.
> > > All that has already been discussed on the mailing list.
> > > 
> > > FPGA loading interface is available here [1].
> > > Patchset missing for FPGA loading has been sent to the mailing list from
> > > Anatolij Gustschin for various Linux kernel versions. Link to the most
> > > recent patchset version [2].
> > > FPGA Manager mailing list archive link [3] - Please read up the story
> > > here around those patches and also the replies of the others.
> > 
> > This does not answer the problem, which perhaps need to be clarified.
> > 
> > Loading FPGA is **not** the problem, I listed it in the things I want to
> > achieve because it is a pre-requirement for the real problem and because
> > the two processes are linked (or could be).
> > 
> > I continue by commenting myself below, trying to make the use case
> > clearer.
> > 
> > > Cheers
> > > Eric
> > > 
> > > [1] https://github.com/vdsao/fpga-cfg
> > > [2] https://marc.info/?l=linux-fpga=155078072107199=2
> > > [3] https://marc.info/?l=linux-fpga
> > > 
> > > Am 10.04.2019 12:01, schrieb Federico Vaga:
> > > > Hello,
> > > > 
> > > > sorry to push for an answer but I do not want to take the risk of
> > > > designing
> > > > something useless. I do not know how should I interpret a no-answer.
> > > > 
> > > > If the solution really does not exist today, then I would like to
> > > > collect
> > > > opinions/arguments/requirements on the topic so that I can write
> > > > something
> > > > useful not only for CERN but for the entire community.
> > > > 
> > > > Thank you
> > > > 
> > > > On Wednesday, March 27, 2019 6:17:18 PM CEST Federico Vaga wrote:
> > > >> Hello,
> > > >> 
> > > >> I'm looking for guidance
> > > >> 
> > > >> What I have:
> > > >> * Intel x86_64 computer
> > > >> * PCIe card with FPGA on it
> > > >> 
> > > >> What I want to achieve:
> > > >> * load an FPGA bitstream on the card
> > > >> * load a device-tree like description for the FPGA devices contained
> > > >> in the bitstream
> > 
> > Let me first elaborate on my knowledge to avoid misunderstandings.
> > 
> > On ARM, nowadays, we boot with a device tree. Later we program an FPGA in
> > which there are other devices described by a device tree overlay. This can
> > be done easily.
> > 
> > A typical PC (x86/x86_64) does not boot with DeviceTree (it is possible,
> > but it is not common and probably not even suggested, not sure), instead
> > it uses ACPI.
> 
> I have heard it suggested that we work on using DT overlays on x86*.
> It's clear there's work to be done to make that work.  I don't know if
> anybody has really tried.  It seems impractical to map or translate a
> x86 systems ACPI into a DT and go from there.  


> One suggestion a few
> years ago was adding a partial DT that had nodes that could serve as
> overlay targets and have that running in parallel with ACPI.

This is also one of my ideas for a solution to our problems. Are you able to 
easily retrieve that conversation? Perhaps this is something on which I can 
work on.

> > The FPGA Manager has support only for DeviceTree (there are patching
> > floating around to load a bitstream with configfs, debugfs or a
> > chardevice (guilty))
> There's one other interface in the kernel upstream. The DFL (device
> feature list) framework built on the FPGA manager/bridge/region stuff
> [5].   It's probably not what 

Re: Device Description for FPGA Components on x86 system

[Federico Vaga]

Hi,

P.S. sorry if I'm too verbose, hopefully it is useful

thanks for the answer

On Wednesday, April 10, 2019 12:30:14 PM CEST Eric Schwarz wrote:
> Hi,
> 
> everything you want is already available and on the way to mainline
> concerning support for various FPGA loading modes or available for
> checkout from a git repository.
> All that has already been discussed on the mailing list.
> 
> FPGA loading interface is available here [1].
> Patchset missing for FPGA loading has been sent to the mailing list from
> Anatolij Gustschin for various Linux kernel versions. Link to the most
> recent patchset version [2].
> FPGA Manager mailing list archive link [3] - Please read up the story
> here around those patches and also the replies of the others.

This does not answer the problem, which perhaps need to be clarified.

Loading FPGA is **not** the problem, I listed it in the things I want to 
achieve because it is a pre-requirement for the real problem and because the 
two processes are linked (or could be).

I continue by commenting myself below, trying to make the use case clearer.

> 
> Cheers
> Eric
> 
> [1] https://github.com/vdsao/fpga-cfg
> [2] https://marc.info/?l=linux-fpga=155078072107199=2
> [3] https://marc.info/?l=linux-fpga
> 
> Am 10.04.2019 12:01, schrieb Federico Vaga:
> > Hello,
> > 
> > sorry to push for an answer but I do not want to take the risk of
> > designing
> > something useless. I do not know how should I interpret a no-answer.
> > 
> > If the solution really does not exist today, then I would like to
> > collect
> > opinions/arguments/requirements on the topic so that I can write
> > something
> > useful not only for CERN but for the entire community.
> > 
> > Thank you
> > 
> > On Wednesday, March 27, 2019 6:17:18 PM CEST Federico Vaga wrote:
> >> Hello,
> >> 
> >> I'm looking for guidance
> >> 
> >> What I have:
> >> * Intel x86_64 computer
> >> * PCIe card with FPGA on it
> >> 
> >> What I want to achieve:
> >> * load an FPGA bitstream on the card
> >> * load a device-tree like description for the FPGA devices contained
> >> in the bitstream

Let me first elaborate on my knowledge to avoid misunderstandings.

On ARM, nowadays, we boot with a device tree. Later we program an FPGA in 
which there are other devices described by a device tree overlay. This can be 
done easily.

A typical PC (x86/x86_64) does not boot with DeviceTree (it is possible, but 
it is not common and probably not even suggested, not sure), instead it uses 
ACPI.

The FPGA Manager has support only for DeviceTree (there are patching floating 
around to load a bitstream with configfs, debugfs or a chardevice (guilty))

Most drivers foresee a DeviceTree loading but not an ACPI one (my feeling, I 
did not extract exact numbers from the sources)

DeviceTree overlay requires that the system boots with DeviceTree.

DeviceTree and ACPI do not work together

So, this is the state of art that I am aware of. Correct me if, and where, I 
am wrong.


Restarting from this point. I have a PC (x86_64) with a PCIe FPGA card (e.g. 
sis8160, spec, links below). How to load the FPGA bitstream (not really a 
problem as you correctly pointed out) **and** load all the IP-core instances 
in that FPGA bitstream so that drivers will start running?

- Is there a recommendation for such use case?
- ACPI SSDT overlay? 
- DT overlay?
- is there a standard way to load FPGA IP-core devices which is architecture 
independent?

A simple and practical example. The i2c-ocore.c is a platform_driver for an 
HDL I2C Master from open cores. I synthesize it and then load it on the FPGA. 
How to create the Linux platform_device instance to driver that IP-core? How 
to do that when you have also IRQ controller(s), DMA engine(s), EEPROM(s) and 
other devices?

The fastest solution is to do what was common on ARM systems: having all 
platform devices declared (hard coded) in a file and load them. Which is not a 
good solution, for the same reasons why arm stuff moved to devicetree.

Is it clearer?

I do not know if it important to highlight but those cards are extensible, 
potentially any FMC module could be plugged and this needs a different FPGA, 
with different FPGA devices etc. So, It is not possible to hardcode the 
description of all possible FPGA code (infinite) that can enable the usage of 
all possible FMC module (not infinite, but definitively grater than 1)


https://www.struck.de/sis8160.html
https://ohwr.org/project/spec/wikis/home


> >> 
> >> This is achievable on ARM with DeviceTree, overlay-dt, fpga-mgr; but
> >> I'm
> >> puzzled about the x86_64 use-case. I'm not able to find recent and
> >> clear
> >> information.
> >> 
> >> Does anyone know if this is doable? Perhaps with ACPI SSDTs overlay?
> >> Or with
> >> the DT?
> >> 
> >> thanks

Re: Device Description for FPGA Components on x86 system

[Federico Vaga]

Hello,

sorry to push for an answer but I do not want to take the risk of designing 
something useless. I do not know how should I interpret a no-answer.

If the solution really does not exist today, then I would like to collect 
opinions/arguments/requirements on the topic so that I can write something 
useful not only for CERN but for the entire community.

Thank you

On Wednesday, March 27, 2019 6:17:18 PM CEST Federico Vaga wrote:
> Hello,
> 
> I'm looking for guidance
> 
> What I have:
> * Intel x86_64 computer
> * PCIe card with FPGA on it
> 
> What I want to achieve:
> * load an FPGA bitstream on the card
> * load a device-tree like description for the FPGA devices contained in the
> bitstream
> 
> This is achievable on ARM with DeviceTree, overlay-dt, fpga-mgr; but I'm
> puzzled about the x86_64 use-case. I'm not able to find recent and clear
> information.
> 
> Does anyone know if this is doable? Perhaps with ACPI SSDTs overlay? Or with
> the DT?
> 
> thanks

Device Description for FPGA Components on x86 system

[Federico Vaga]

Hello,

I'm looking for guidance

What I have:
* Intel x86_64 computer
* PCIe card with FPGA on it

What I want to achieve:
* load an FPGA bitstream on the card
* load a device-tree like description for the FPGA devices contained in the 
bitstream

This is achievable on ARM with DeviceTree, overlay-dt, fpga-mgr; but I'm 
puzzled about the x86_64 use-case. I'm not able to find recent and clear 
information.

Does anyone know if this is doable? Perhaps with ACPI SSDTs overlay? Or with 
the DT?

thanks 

Re: [RFC PATCH] doc: translation disclaimer

[Federico Vaga]

Hi Alex,

On Wednesday, March 6, 2019 2:57:05 AM CET Alex Shi wrote:
> Generally It looks good! A short guide to translator is good as well as a
> disclaimer.
> On 2019/3/6 6:06 上午, Federico Vaga wrote:
> > This is only an example to propose a structure for translation's
> > disclaimers. The actual text needs some thoughs.
> > 
> > Signed-off-by: Federico Vaga 
> > ---
> > 
> >  Documentation/translations/index.rst   | 18 ++
> >  .../translations/it_IT/disclaimer-ita.rst  | 13 +++--
> >  Documentation/translations/it_IT/index.rst |  6 ++
> >  3 files changed, 27 insertions(+), 10 deletions(-)
> > 
> > diff --git a/Documentation/translations/index.rst
> > b/Documentation/translations/index.rst index 7f77c52d33aa..b46c8ce98d6e
> > 100644
> > --- a/Documentation/translations/index.rst
> > +++ b/Documentation/translations/index.rst
> > @@ -4,6 +4,24 @@
> > 
> >  Translations
> >  
> > 
> > +.. _translations_disclaimer:
> > +
> > +Disclaimer
> > +--
> > +Write some text in English here to explain that:
> > +
> > +- its purpose is to ease reading and understanding in other languages
> > +- this is not a fork
> > +- the only official documentation is :ref:`linux_doc`
> 
> Could we merge the 2nd and 3rd into one, like this is not a fork of original
> file :ref:``

yes

> > +- there are not guarantee about translations being in line with the
> > +  main documentation
> 
> Could we merge this one with 1st item, like its purpose is to  without
> any guarantee of translations 

yes, why not.

I did a list of items to separate the ingredients for the final text.

> > +- translation's maintainer can help people who can't write in English
> > +- only comments and patches about translations are accepted, any other
> > +  discussion about Documentation does not belong here.
> 
> I am not very good at English. is the following words are bit more clear?
> like, only translation related update are accepted here, contents change
> need goes to original files ...

As I wrote in the commit message, this is just a  example to show the 
structure and share the main message.

What I wrote is just a 10 minutes sketch, to share an idea. This is **not** 
the text that I'm proposing; what I'm proposing here are the structure and the 
concepts/ideas/messages. The final patch will be written appropriately, but 
before doing it I would like to collect the messages that we want to put in 
it; I listed above what I think is necessary to say.

> > +
> > +Translations
> > +
> > +
> > 
> >  .. toctree::
> > :maxdepth: 1
> > 
> > diff --git a/Documentation/translations/it_IT/disclaimer-ita.rst
> > b/Documentation/translations/it_IT/disclaimer-ita.rst index
> > d68e52de6a5d..aacc1a0346db 100644
> > --- a/Documentation/translations/it_IT/disclaimer-ita.rst
> > +++ b/Documentation/translations/it_IT/disclaimer-ita.rst
> > @@ -1,13 +1,6 @@
> > 
> >  :orphan:
> why the orphan here? does that mean no maintainer for it_IT currently?

It is a Sphinx tag to avoid warnings at build time. Instead of re-writing 
exactly the same text in all files, this one is included at the top of all 
translated documents. But, since it is not a real document this is not 
included in any TOC and sphinx complains; that's why we need the orphan tag

http://www.sphinx-doc.org/en/master/usage/restructuredtext/field-lists.html#metadata

> 
> Thanks
> Alex
> 
> > -.. note::
> > -   This document is maintained by Federico Vaga
> > . -   If you find any difference between this
> > document and the original file or a -   problem with the translation,
> > please contact the maintainer of this file. -   Following people helped
> > to translate or review:
> > -   Alessia Mantegazza 
> > -
> > 
> >  .. warning::
> > -   The purpose of this file is to be easier to read and understand for
> > Italian -   speakers and is not intended as a fork. So, if you have any
> > comments or -   updates for this file please try to update the original
> > English file first. +   Short (to not pollute the document) text in
> > Italian to explain that for any +   doubt about the documentation content
> > people should refer to the English +   documentation. Read the
> > :ref:`it_disclaimer`.
> > diff --git a/Documentation/translations/it_IT/index.rst
> > b/Documentation/translations/it_IT/index.rst index
> > ea9b2916b3e4..4b0b3da97c73 100644
> > --- a/Documentation/translations/it_IT/index.rst
> > +++ b/Documentation/transl

[RFC PATCH] doc: translation disclaimer

[Federico Vaga]

This is only an example to propose a structure for translation's
disclaimers. The actual text needs some thoughs.

Signed-off-by: Federico Vaga 
---
 Documentation/translations/index.rst   | 18 ++
 .../translations/it_IT/disclaimer-ita.rst  | 13 +++--
 Documentation/translations/it_IT/index.rst |  6 ++
 3 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/Documentation/translations/index.rst 
b/Documentation/translations/index.rst
index 7f77c52d33aa..b46c8ce98d6e 100644
--- a/Documentation/translations/index.rst
+++ b/Documentation/translations/index.rst
@@ -4,6 +4,24 @@
 Translations
 
 
+.. _translations_disclaimer:
+
+Disclaimer
+--
+Write some text in English here to explain that:
+
+- its purpose is to ease reading and understanding in other languages
+- this is not a fork
+- the only official documentation is :ref:`linux_doc`
+- there are not guarantee about translations being in line with the
+  main documentation
+- translation's maintainer can help people who can't write in English
+- only comments and patches about translations are accepted, any other
+  discussion about Documentation does not belong here
+
+Translations
+
+
 .. toctree::
:maxdepth: 1
 
diff --git a/Documentation/translations/it_IT/disclaimer-ita.rst 
b/Documentation/translations/it_IT/disclaimer-ita.rst
index d68e52de6a5d..aacc1a0346db 100644
--- a/Documentation/translations/it_IT/disclaimer-ita.rst
+++ b/Documentation/translations/it_IT/disclaimer-ita.rst
@@ -1,13 +1,6 @@
 :orphan:
 
-.. note::
-   This document is maintained by Federico Vaga .
-   If you find any difference between this document and the original file or a
-   problem with the translation, please contact the maintainer of this file.
-   Following people helped to translate or review:
-   Alessia Mantegazza 
-
 .. warning::
-   The purpose of this file is to be easier to read and understand for Italian
-   speakers and is not intended as a fork. So, if you have any comments or
-   updates for this file please try to update the original English file first.
+   Short (to not pollute the document) text in Italian to explain that for any
+   doubt about the documentation content people should refer to the English
+   documentation. Read the :ref:`it_disclaimer`.
diff --git a/Documentation/translations/it_IT/index.rst 
b/Documentation/translations/it_IT/index.rst
index ea9b2916b3e4..4b0b3da97c73 100644
--- a/Documentation/translations/it_IT/index.rst
+++ b/Documentation/translations/it_IT/index.rst
@@ -4,6 +4,12 @@
 Traduzione italiana
 ===
 
+.. _it_disclaimer:
+
+Disclaimer
+==
+The following text should be the translation of :ref:`translations_disclaimer`
+
 L'obiettivo di questa traduzione è di rendere più facile la lettura e
 la comprensione per chi preferisce leggere in lingua italiana.
 Tenete presente che la documentazione di riferimento rimane comunque
-- 
2.20.1

Re: [PATCH 01/20] docs/zh_CN: add disclaimer file

[Federico Vaga]

On 2019-03-04 23:06, Li Yang wrote:
On Sun, Mar 3, 2019 at 10:03 PM Alex Shi  
wrote:


This a disclaimer file which will be included in Chinese files
as header. To reduce the same common contents copy.


It is great for reducing the duplication.  But since this is in the
translation folder, probably it will be even better to include a
translated version of this disclaimer too?


In the Italian translation I wrote the disclaimer in English because it
contains information also for non-Italian readers.
I understand both prospectives and I do not have a strong opinion. The 
only
strong opinion that I have concern consistency: we should do all the 
same.


I will propose an RFC patch with a compromise solution (it will be 
easier
than explaining it) based on the Italian translation (no need to know 
Italian)



Regards,
Leo



Most of contents quoted from Federico Vaga's file:
Documentation/translations/it_IT/disclaimer-ita.rst.
Thanks a lot!

Signed-off-by: Alex Shi 
Cc: Harry Wei 
Cc: Jonathan Corbet 
Cc: Li Zefan 
Cc: Shawn Guo 
Cc: Fengguang Wu 
Cc: Coly Li 
Cc: Federico Vaga 
---
 Documentation/translations/zh_CN/disclaimer-zh_CN.rst | 11 
+++

 1 file changed, 11 insertions(+)
 create mode 100644 
Documentation/translations/zh_CN/disclaimer-zh_CN.rst


diff --git a/Documentation/translations/zh_CN/disclaimer-zh_CN.rst 
b/Documentation/translations/zh_CN/disclaimer-zh_CN.rst

new file mode 100644
index ..0de5dfb069ca
--- /dev/null
+++ b/Documentation/translations/zh_CN/disclaimer-zh_CN.rst
@@ -0,0 +1,11 @@
+:orphan:
+
+.. warning::
+   The purpose of this file is to be easier to read and understand 
for Chinese
+   speakers and is not intended as a fork. So, if you have any 
comments or
+   updates for this file please try to update the original English 
file first.

+
+.. note::
+   If you find any difference between this document and the original 
file or a
+   problem with the translation, please contact the maintainer of 
this file,

+   or get help from Alex Shi 
--
2.19.1.856.g8858448bb



--
Federico Vaga
http://www.federicovaga.it/

[PATCH] doc:it_IT: translations for documents in process/

[Federico Vaga]

Translated documents:
- stable-kernel-rules.rst
- deprecated.rst
- kernel-enforcement-statement.rst
- license-rules.rst

Added document to have valid links
- netdev-FAQ.rst

Modifications to main documentation
- add label in deprecated.rst

Signed-off-by: Federico Vaga 
---
 Documentation/process/deprecated.rst  |   2 +
 Documentation/translations/it_IT/index.rst|   8 +-
 .../it_IT/networking/netdev-FAQ.rst   |  13 +
 .../translations/it_IT/process/deprecated.rst | 129 +
 .../process/kernel-enforcement-statement.rst  | 168 ++-
 .../it_IT/process/license-rules.rst   | 452 ++
 .../it_IT/process/stable-kernel-rules.rst | 194 +++-
 7 files changed, 954 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/translations/it_IT/networking/netdev-FAQ.rst
 create mode 100644 Documentation/translations/it_IT/process/deprecated.rst
 create mode 100644 Documentation/translations/it_IT/process/license-rules.rst

diff --git a/Documentation/process/deprecated.rst 
b/Documentation/process/deprecated.rst
index 0ef5a63c06ba..49e0f64a3427 100644
--- a/Documentation/process/deprecated.rst
+++ b/Documentation/process/deprecated.rst
@@ -1,5 +1,7 @@
 .. SPDX-License-Identifier: GPL-2.0
 
+.. _deprecated:
+
 =
 Deprecated Interfaces, Language Features, Attributes, and Conventions
 =
diff --git a/Documentation/translations/it_IT/index.rst 
b/Documentation/translations/it_IT/index.rst
index ea9b2916b3e4..02432b97a43e 100644
--- a/Documentation/translations/it_IT/index.rst
+++ b/Documentation/translations/it_IT/index.rst
@@ -47,9 +47,7 @@ I seguenti documenti descrivono la licenza usata nei sorgenti 
del kernel Linux
 (GPLv2), come licenziare i singoli file; inoltre troverete i riferimenti al
 testo integrale della licenza.
 
-.. warning::
-
-TODO ancora da tradurre
+* :ref:`it_kernel_licensing`
 
 Documentazione per gli utenti
 -
@@ -90,10 +88,6 @@ vostre modifiche molto più semplice
doc-guide/index
kernel-hacking/index
 
-.. warning::
-
-TODO ancora da tradurre
-
 Documentazione della API del kernel
 ---
 
diff --git a/Documentation/translations/it_IT/networking/netdev-FAQ.rst 
b/Documentation/translations/it_IT/networking/netdev-FAQ.rst
new file mode 100644
index ..8489ead7cff1
--- /dev/null
+++ b/Documentation/translations/it_IT/networking/netdev-FAQ.rst
@@ -0,0 +1,13 @@
+.. include:: ../disclaimer-ita.rst
+
+:Original: :ref:`Documentation/process/stable-kernel-rules.rst 
`
+
+.. _it_netdev-FAQ:
+
+==
+netdev FAQ
+==
+
+.. warning::
+
+TODO ancora da tradurre
diff --git a/Documentation/translations/it_IT/process/deprecated.rst 
b/Documentation/translations/it_IT/process/deprecated.rst
new file mode 100644
index ..776f26732a94
--- /dev/null
+++ b/Documentation/translations/it_IT/process/deprecated.rst
@@ -0,0 +1,129 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../disclaimer-ita.rst
+
+:Original: :ref:`Documentation/process/deprecated.rst `
+:Translator: Federico Vaga 
+
+.. _it_deprecated:
+
+==
+Interfacce deprecate, caratteristiche del linguaggio, attributi, e convenzioni
+==
+
+In un mondo perfetto, sarebbe possibile prendere tutti gli usi di
+un'interfaccia deprecata e convertirli in quella nuova, e così sarebbe
+possibile rimuovere la vecchia interfaccia in un singolo ciclo di sviluppo.
+Tuttavia, per via delle dimensioni del kernel, la gerarchia dei manutentori e
+le tempistiche, non è sempre possibile fare questo tipo di conversione tutta
+in una volta. Questo significa che nuove istanze di una vecchia interfaccia
+potrebbero aggiungersi al kernel proprio quando si sta cercando di rimuoverle,
+aumentando così il carico di lavoro. Al fine di istruire gli sviluppatori su
+cosa è considerato deprecato (e perché), è stata create la seguente lista a cui
+fare riferimento quando qualcuno propone modifiche che usano cose deprecate.
+
+__deprecated
+
+Nonostante questo attributo marchi visibilmente un interfaccia come deprecata,
+`non produce più alcun avviso durante la compilazione
+<https://git.kernel.org/linus/771c035372a036f83353eef46dbb829780330234>`_
+perché uno degli obiettivi del kernel è quello di compilare senza avvisi;
+inoltre, nessuno stava agendo per rimuovere queste interfacce. Nonostante l'uso
+di `__deprecated` in un file d'intestazione sia opportuno per segnare una
+interfaccia come 'vecchia', questa non è una soluzione completa. L'interfaccia
+deve essere rimossa dal kernel, o aggiunta a questo documento per scoraggiarne
+l'uso.
+
+Calcoli codificati negli argomenti di un allo

Re: [PATCH] Documentation/process/howto: Update for 4.x -> 5.x versioning

[Federico Vaga]

hello,

I have just a general observation for the community, not related to the 
content of this patch, but related with the idea behind.

Is it really important to specify the major release number in the documents? . 
Can't we just use a generic x.y.z, or a more generic statement?

When you open a documentation page like

https://www.kernel.org/doc/html/latest/

you will see the release number in the top left corner, which implies that 
what you read is (should be) valid for that version. And if you read from the 
sources you should know which version you checked out, and if you don't you
can always verify.

I do not see the added value of having those numbers in the documents, unless 
the purpose is to highlight some specific exceptions.

Am I missing some important reasons that justify these numbers?

Thank you

On Sunday, February 24, 2019 9:43:20 AM CET Zenghui Yu wrote:
> As linux-5.0 is coming up soon, the howto.rst document can be
> updated for the new kernel version. Change all 4.x references
> to 5.x now.
> 
> Signed-off-by: Zenghui Yu 
> ---
>  Documentation/process/howto.rst | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/process/howto.rst
> b/Documentation/process/howto.rst index f16242b..19001e2 100644
> --- a/Documentation/process/howto.rst
> +++ b/Documentation/process/howto.rst
> @@ -235,16 +235,16 @@ Linux kernel development process currently
> consists of a few different
>  main kernel "branches" and lots of different subsystem-specific kernel
>  branches.  These different branches are:
> 
> -  - main 4.x kernel tree
> -  - 4.x.y -stable kernel tree
> +  - main 5.x kernel tree
> +  - 5.x.y -stable kernel tree
>- subsystem specific kernel trees and patches
> -  - the 4.x -next kernel tree for integration tests
> +  - the 5.x -next kernel tree for integration tests
> 
> -4.x kernel tree
> +5.x kernel tree
>  ~~~
> 
> -4.x kernels are maintained by Linus Torvalds, and can be found on
> -https://kernel.org in the pub/linux/kernel/v4.x/ directory.  Its
> development +5.x kernels are maintained by Linus Torvalds, and can be found
> on +https://kernel.org in the pub/linux/kernel/v5.x/ directory.  Its
> development process is as follows:
> 
>- As soon as a new kernel is released a two weeks window is open,
> @@ -277,21 +277,21 @@ mailing list about kernel releases:
>   released according to perceived bug status, not according to a
>   preconceived timeline."*
> 
> -4.x.y -stable kernel tree
> +5.x.y -stable kernel tree
>  ~
> 
>  Kernels with 3-part versions are -stable kernels. They contain
>  relatively small and critical fixes for security problems or significant
> -regressions discovered in a given 4.x kernel.
> +regressions discovered in a given 5.x kernel.
> 
>  This is the recommended branch for users who want the most recent stable
>  kernel and are not interested in helping test development/experimental
>  versions.
> 
> -If no 4.x.y kernel is available, then the highest numbered 4.x
> +If no 5.x.y kernel is available, then the highest numbered 5.x
>  kernel is the current stable kernel.
> 
> -4.x.y are maintained by the "stable" team , and
> +5.x.y are maintained by the "stable" team , and
>  are released as needs dictate.  The normal release period is approximately
>  two weeks, but it can be longer if there are no pressing problems.  A
>  security-related problem, instead, can cause a release to happen almost
> @@ -326,10 +326,10 @@ revisions to it, and maintainers can mark
> patches as under review,
>  accepted, or rejected.  Most of these patchwork sites are listed at
>  https://patchwork.kernel.org/.
> 
> -4.x -next kernel tree for integration tests
> +5.x -next kernel tree for integration tests
>  ~~~
> 
> -Before updates from subsystem trees are merged into the mainline 4.x
> +Before updates from subsystem trees are merged into the mainline 5.x
>  tree, they need to be integration-tested.  For this purpose, a special
>  testing repository exists into which virtually all subsystem trees are
>  pulled on an almost daily basis:

[PATCH v2 2/2] doc: process: complete removal of info about -git patches

[Federico Vaga]

The following patch forgot to remove a reference to the -git
patches

commit 2c71d305caf9 ("docs: process: Remove outdated info about -git patches")

This patch complete the removal and update all translations

Signed-off-by: Federico Vaga 
---
 Documentation/process/howto.rst| 1 -
 Documentation/translations/it_IT/process/howto.rst | 1 -
 Documentation/translations/ja_JP/howto.rst | 1 -
 Documentation/translations/ko_KR/howto.rst | 1 -
 Documentation/translations/zh_CN/HOWTO | 1 -
 5 files changed, 5 deletions(-)

diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
index bdd2eda81a1c..80488a5e6738 100644
--- a/Documentation/process/howto.rst
+++ b/Documentation/process/howto.rst
@@ -237,7 +237,6 @@ branches.  These different branches are:
 
   - main 4.x kernel tree
   - 4.x.y -stable kernel tree
-  - 4.x -git kernel patches
   - subsystem specific kernel trees and patches
   - the 4.x -next kernel tree for integration tests
 
diff --git a/Documentation/translations/it_IT/process/howto.rst 
b/Documentation/translations/it_IT/process/howto.rst
index 15199aa5b4df..9903ac7c566b 100644
--- a/Documentation/translations/it_IT/process/howto.rst
+++ b/Documentation/translations/it_IT/process/howto.rst
@@ -244,7 +244,6 @@ e di molti altri rami per specifici sottosistemi. Questi 
rami sono:
 
   - I sorgenti kernel 4.x
   - I sorgenti stabili del kernel 4.x.y -stable
-  - Le modifiche in 4.x -git
   - Sorgenti dei sottosistemi del kernel e le loro modifiche
   - Il kernel 4.x -next per test d'integrazione
 
diff --git a/Documentation/translations/ja_JP/howto.rst 
b/Documentation/translations/ja_JP/howto.rst
index 4fbf40552728..2621b770a745 100644
--- a/Documentation/translations/ja_JP/howto.rst
+++ b/Documentation/translations/ja_JP/howto.rst
@@ -256,7 +256,6 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメイン
 
   - メインの 4.x カーネルツリー
   - 4.x.y -stable カーネルツリー
-  - 4.x -git カーネルパッチ
   - サブシステム毎のカーネルツリーとパッチ
   - 統合テストのための 4.x -next カーネルツリー
 
diff --git a/Documentation/translations/ko_KR/howto.rst 
b/Documentation/translations/ko_KR/howto.rst
index d8acf255ac5f..bcd63731b80a 100644
--- a/Documentation/translations/ko_KR/howto.rst
+++ b/Documentation/translations/ko_KR/howto.rst
@@ -242,7 +242,6 @@ ReST 마크업을 사용하는 문서들은 Documentation/output 에 생성된
 
   - main 4.x 커널 트리
   - 4.x.y - 안정된 커널 트리
-  - 4.x -git 커널 패치들
   - 서브시스템을 위한 커널 트리들과 패치들
   - 4.x - 통합 테스트를 위한 next 커널 트리
 
diff --git a/Documentation/translations/zh_CN/HOWTO 
b/Documentation/translations/zh_CN/HOWTO
index 8e7dee80a087..7a00a8a4eb15 100644
--- a/Documentation/translations/zh_CN/HOWTO
+++ b/Documentation/translations/zh_CN/HOWTO
@@ -192,7 +192,6 @@ Linux内核代码中包含有大量的文档。这些文档对于学习如何与
 些分支包括：
   - 2.6.x主内核源码树
   - 2.6.x.y -stable内核源码树
-  - 2.6.x -git内核补丁集
   - 2.6.x -mm内核补丁集
   - 子系统相关的内核源码树和补丁集
 
-- 
2.20.1

[PATCH v2 1/2] doc: translations: sync translations 'remove info about -git patches'

[Federico Vaga]

Synchonise translations: CN, IT, JP, KR

commit 2c71d305caf9 ("docs: process: Remove outdated info about -git patches")

I can guarantee for the Italian translations, but since we are removing
an entire chapter I think I did it right also for the other languages.

Signed-off-by: Federico Vaga 
---
 Documentation/translations/it_IT/process/howto.rst | 10 --
 Documentation/translations/ja_JP/howto.rst |  9 -
 Documentation/translations/ko_KR/howto.rst |  8 
 Documentation/translations/zh_CN/HOWTO |  8 
 4 files changed, 35 deletions(-)

diff --git a/Documentation/translations/it_IT/process/howto.rst 
b/Documentation/translations/it_IT/process/howto.rst
index f9a44b1af89d..15199aa5b4df 100644
--- a/Documentation/translations/it_IT/process/howto.rst
+++ b/Documentation/translations/it_IT/process/howto.rst
@@ -313,16 +313,6 @@ Il file Documentation/process/stable-kernel-rules.rst (nei 
sorgenti) documenta
 quali tipologie di modifiche sono accettate per i sorgenti -stable, e come
 avviene il processo di rilascio.
 
-Le modifiche in 4.x -git
-
-
-Queste sono istantanee quotidiane del kernel di Linus e sono gestite in
-una repositorio git (da qui il nome). Queste modifiche sono solitamente
-rilasciate giornalmente e rappresentano l'attuale stato dei sorgenti di
-Linus. Queste sono da considerarsi più sperimentali di un -rc in quanto
-generate automaticamente senza nemmeno aver dato una rapida occhiata
-per verificarne lo stato.
-
 
 Sorgenti dei sottosistemi del kernel e le loro patch
 
diff --git a/Documentation/translations/ja_JP/howto.rst 
b/Documentation/translations/ja_JP/howto.rst
index 2ca9389d5915..4fbf40552728 100644
--- a/Documentation/translations/ja_JP/howto.rst
+++ b/Documentation/translations/ja_JP/howto.rst
@@ -319,15 +319,6 @@ Documentation/process/stable-kernel-rules.rst ファイルにはどのような
 類の変更が -stable ツリーに受け入れ可能か、またリリースプロセスがどう
 動くかが記述されています。
 
-4.x -git パッチ
-~~~
-
-git リポジトリで管理されているLinus のカーネルツリーの毎日のスナップ
-ショットがあります。(だから -git という名前がついています)。これらのパッ
-チはおおむね毎日リリースされており、Linus のツリーの現状を表します。こ
-れは -rc カーネルと比べて、パッチが大丈夫かどうかも確認しないで自動的
-に生成されるので、より実験的です。
-
 サブシステム毎のカーネルツリーとパッチ
 ~~
 
diff --git a/Documentation/translations/ko_KR/howto.rst 
b/Documentation/translations/ko_KR/howto.rst
index 528433932589..d8acf255ac5f 100644
--- a/Documentation/translations/ko_KR/howto.rst
+++ b/Documentation/translations/ko_KR/howto.rst
@@ -302,14 +302,6 @@ Andrew Morton의 글이 있다.
 파일은 어떤 종류의 변경들이 -stable 트리로 들어왔는지와
 배포 프로세스가 어떻게 진행되는지를 설명한다.
 
-4.x -git 패치들
-~~~
-
-git 저장소(그러므로 -git이라는 이름이 붙음)에는 날마다 관리되는 Linus의
-커널 트리의 snapshot 들이 있다. 이 패치들은 일반적으로 날마다 배포되며
-Linus의 트리의 현재 상태를 나타낸다. 이 패치들은 정상적인지 조금도
-살펴보지 않고 자동적으로 생성된 것이므로 -rc 커널들 보다도 더 실험적이다.
-
 서브시스템 커널 트리들과 패치들
 ~~~
 
diff --git a/Documentation/translations/zh_CN/HOWTO 
b/Documentation/translations/zh_CN/HOWTO
index 5f6d09edc9ac..8e7dee80a087 100644
--- a/Documentation/translations/zh_CN/HOWTO
+++ b/Documentation/translations/zh_CN/HOWTO
@@ -240,14 +240,6 @@ kernel.org网站的pub/linux/kernel/v2.6/目录下找到它。它的开发遵循
 版内核接受的修改类型以及发布的流程。
 
 
-2.6.x -git补丁集
-
-Linus的内核源码树的每日快照，这个源码树是由git工具管理的（由此得名）。这
-些补丁通常每天更新以反映Linus的源码树的最新状态。它们比-rc版本的内核源码
-树更具试验性质，因为这个补丁集是全自动生成的，没有任何人来确认其是否真正
-健全。
-
-
 2.6.x -mm补丁集
 ---
 这是由Andrew Morton维护的试验性内核补丁集。Andrew将所有子系统的内核源码
-- 
2.20.1

[PATCH 2/2] doc: process: complete removal of info about -git patches

[Federico Vaga]

The following patch forgot to remove a reference to the -git
patches

commit 2c71d305caf9 ("docs: process: Remove outdated info about -git patches")

This patch complete the removal and update all translations

Signed-off-by: Federico Vaga 
---
 Documentation/process/howto.rst| 1 -
 Documentation/translations/it_IT/process/howto.rst | 1 -
 Documentation/translations/ja_JP/howto.rst | 1 -
 Documentation/translations/ko_KR/howto.rst | 1 -
 Documentation/translations/zh_CN/HOWTO | 1 -
 5 files changed, 5 deletions(-)

diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
index bdd2eda81a1c..80488a5e6738 100644
--- a/Documentation/process/howto.rst
+++ b/Documentation/process/howto.rst
@@ -237,7 +237,6 @@ branches.  These different branches are:
 
   - main 4.x kernel tree
   - 4.x.y -stable kernel tree
-  - 4.x -git kernel patches
   - subsystem specific kernel trees and patches
   - the 4.x -next kernel tree for integration tests
 
diff --git a/Documentation/translations/it_IT/process/howto.rst 
b/Documentation/translations/it_IT/process/howto.rst
index 15199aa5b4df..9903ac7c566b 100644
--- a/Documentation/translations/it_IT/process/howto.rst
+++ b/Documentation/translations/it_IT/process/howto.rst
@@ -244,7 +244,6 @@ e di molti altri rami per specifici sottosistemi. Questi 
rami sono:
 
   - I sorgenti kernel 4.x
   - I sorgenti stabili del kernel 4.x.y -stable
-  - Le modifiche in 4.x -git
   - Sorgenti dei sottosistemi del kernel e le loro modifiche
   - Il kernel 4.x -next per test d'integrazione
 
diff --git a/Documentation/translations/ja_JP/howto.rst 
b/Documentation/translations/ja_JP/howto.rst
index 8de41a6ce984..4867cb9b6600 100644
--- a/Documentation/translations/ja_JP/howto.rst
+++ b/Documentation/translations/ja_JP/howto.rst
@@ -256,7 +256,6 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメイン
 
   - メインの 4.x カーネルツリー
   - 4.x.y -stable カーネルツリー
-  - 4.x -git カーネルパッチ
   - サブシステム毎のカーネルツリーとパッチ
   - 統合テストのための 4.x -next カーネルツリー
 
diff --git a/Documentation/translations/ko_KR/howto.rst 
b/Documentation/translations/ko_KR/howto.rst
index d8fc7c31bde9..50992cac562f 100644
--- a/Documentation/translations/ko_KR/howto.rst
+++ b/Documentation/translations/ko_KR/howto.rst
@@ -242,7 +242,6 @@ ReST 마크업을 사용하는 문서들은 Documentation/output 에 생성된
 
   - main 4.x 커널 트리
   - 4.x.y - 안정된 커널 트리
-  - 4.x -git 커널 패치들
   - 서브시스템을 위한 커널 트리들과 패치들
   - 4.x - 통합 테스트를 위한 next 커널 트리
 
diff --git a/Documentation/translations/zh_CN/HOWTO 
b/Documentation/translations/zh_CN/HOWTO
index 8e7dee80a087..7a00a8a4eb15 100644
--- a/Documentation/translations/zh_CN/HOWTO
+++ b/Documentation/translations/zh_CN/HOWTO
@@ -192,7 +192,6 @@ Linux内核代码中包含有大量的文档。这些文档对于学习如何与
 些分支包括：
   - 2.6.x主内核源码树
   - 2.6.x.y -stable内核源码树
-  - 2.6.x -git内核补丁集
   - 2.6.x -mm内核补丁集
   - 子系统相关的内核源码树和补丁集
 
-- 
2.20.1

[PATCH 1/2] doc: translations: sync translations 'remove info about -git patches'

[Federico Vaga]

Synchonise translations: CN, IT, JP, KR

commit 2c71d305caf9 ("docs: process: Remove outdated info about -git patches")

I can guarantee for the Italian translations, but since we are removing
an entire chapter I think I did it right also for the other languages.

Signed-off-by: Federico Vaga 
---
 Documentation/translations/it_IT/process/howto.rst | 10 --
 Documentation/translations/ja_JP/howto.rst |  8 
 Documentation/translations/ko_KR/howto.rst |  7 ---
 Documentation/translations/zh_CN/HOWTO |  8 
 4 files changed, 33 deletions(-)

diff --git a/Documentation/translations/it_IT/process/howto.rst 
b/Documentation/translations/it_IT/process/howto.rst
index f9a44b1af89d..15199aa5b4df 100644
--- a/Documentation/translations/it_IT/process/howto.rst
+++ b/Documentation/translations/it_IT/process/howto.rst
@@ -313,16 +313,6 @@ Il file Documentation/process/stable-kernel-rules.rst (nei 
sorgenti) documenta
 quali tipologie di modifiche sono accettate per i sorgenti -stable, e come
 avviene il processo di rilascio.
 
-Le modifiche in 4.x -git
-
-
-Queste sono istantanee quotidiane del kernel di Linus e sono gestite in
-una repositorio git (da qui il nome). Queste modifiche sono solitamente
-rilasciate giornalmente e rappresentano l'attuale stato dei sorgenti di
-Linus. Queste sono da considerarsi più sperimentali di un -rc in quanto
-generate automaticamente senza nemmeno aver dato una rapida occhiata
-per verificarne lo stato.
-
 
 Sorgenti dei sottosistemi del kernel e le loro patch
 
diff --git a/Documentation/translations/ja_JP/howto.rst 
b/Documentation/translations/ja_JP/howto.rst
index 2ca9389d5915..8de41a6ce984 100644
--- a/Documentation/translations/ja_JP/howto.rst
+++ b/Documentation/translations/ja_JP/howto.rst
@@ -319,14 +319,6 @@ Documentation/process/stable-kernel-rules.rst ファイルにはどのような
 類の変更が -stable ツリーに受け入れ可能か、またリリースプロセスがどう
 動くかが記述されています。
 
-4.x -git パッチ
-~~~
-
-git リポジトリで管理されているLinus のカーネルツリーの毎日のスナップ
-ショットがあります。(だから -git という名前がついています)。これらのパッ
-チはおおむね毎日リリースされており、Linus のツリーの現状を表します。こ
-れは -rc カーネルと比べて、パッチが大丈夫かどうかも確認しないで自動的
-に生成されるので、より実験的です。
 
 サブシステム毎のカーネルツリーとパッチ
 ~~
diff --git a/Documentation/translations/ko_KR/howto.rst 
b/Documentation/translations/ko_KR/howto.rst
index 528433932589..d8fc7c31bde9 100644
--- a/Documentation/translations/ko_KR/howto.rst
+++ b/Documentation/translations/ko_KR/howto.rst
@@ -302,13 +302,6 @@ Andrew Morton의 글이 있다.
 파일은 어떤 종류의 변경들이 -stable 트리로 들어왔는지와
 배포 프로세스가 어떻게 진행되는지를 설명한다.
 
-4.x -git 패치들
-~~~
-
-git 저장소(그러므로 -git이라는 이름이 붙음)에는 날마다 관리되는 Linus의
-커널 트리의 snapshot 들이 있다. 이 패치들은 일반적으로 날마다 배포되며
-Linus의 트리의 현재 상태를 나타낸다. 이 패치들은 정상적인지 조금도
-살펴보지 않고 자동적으로 생성된 것이므로 -rc 커널들 보다도 더 실험적이다.
 
 서브시스템 커널 트리들과 패치들
 ~~~
diff --git a/Documentation/translations/zh_CN/HOWTO 
b/Documentation/translations/zh_CN/HOWTO
index 5f6d09edc9ac..8e7dee80a087 100644
--- a/Documentation/translations/zh_CN/HOWTO
+++ b/Documentation/translations/zh_CN/HOWTO
@@ -240,14 +240,6 @@ kernel.org网站的pub/linux/kernel/v2.6/目录下找到它。它的开发遵循
 版内核接受的修改类型以及发布的流程。
 
 
-2.6.x -git补丁集
-
-Linus的内核源码树的每日快照，这个源码树是由git工具管理的（由此得名）。这
-些补丁通常每天更新以反映Linus的源码树的最新状态。它们比-rc版本的内核源码
-树更具试验性质，因为这个补丁集是全自动生成的，没有任何人来确认其是否真正
-健全。
-
-
 2.6.x -mm补丁集
 ---
 这是由Andrew Morton维护的试验性内核补丁集。Andrew将所有子系统的内核源码
-- 
2.20.1

[PATCH] doc: fix typos in license-rules.rst

[Federico Vaga]

The patches fixes some typos in process/license-rules.rst

Signed-off-by: Federico Vaga 
---
 Documentation/process/license-rules.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/process/license-rules.rst 
b/Documentation/process/license-rules.rst
index 2bb8c0fc2238..d9798d61fe64 100644
--- a/Documentation/process/license-rules.rst
+++ b/Documentation/process/license-rules.rst
@@ -62,7 +62,7 @@ License identifier syntax
 
The SPDX license identifier in kernel files shall be added at the first
possible line in a file which can contain a comment.  For the majority
-   or files this is the first line, except for scripts which require the
+   of files this is the first line, except for scripts which require the
'#!PATH_TO_INTERPRETER' in the first line.  For those scripts the SPDX
identifier goes into the second line.
 
@@ -368,7 +368,7 @@ kernel, can be broken down into:
 
 
 All SPDX license identifiers and exceptions must have a corresponding file
-in the LICENSE subdirectories. This is required to allow tool
+in the LICENSES subdirectories. This is required to allow tool
 verification (e.g. checkpatch.pl) and to have the licenses ready to read
 and extract right from the source, which is recommended by various FOSS
 organizations, e.g. the `FSFE REUSE initiative <https://reuse.software/>`_.
-- 
2.20.1

Re: report: scripts: checkpatch: Spell Checker Does Not Run with '-f'

[Federico Vaga]

On Thursday, February 14, 2019 4:19:36 PM CET Joe Perches wrote:
> On Thu, 2019-02-14 at 16:03 +0100, Federico Vaga wrote:
> > On Thursday, February 14, 2019 3:44:55 PM CET Joe Perches wrote:
> > > On Thu, 2019-02-14 at 13:48 +0100, Federico Vaga wrote:
> > > > Hello,
> > > > 
> > > > Recently I have produce a couple of patches but I get different
> > > > warnings
> > > > if I run checkpatch on the file (-f) or if I run it of a patch file.
> > > > In
> > > > particular, the problem I found is with the spell checker which seems
> > > > to
> > > > run only when the option '-f' is not used. I am wandering if there are
> > > > other similar cases.
> > > > 
> > > > I do not know Perl, so I cannot investigate more, but I have a
> > > > practical
> > > > example. I have this simple patch applied on my tree that introduces a
> > > > spell
> > > 
> > > > error:
> > > If you want spelling fixes on files you have to use --strict
> > 
> > Thanks
> > 
> > Is it a design choice to have different checks enabled with '-f'?
> 
> Yes.
> 
> It was for a minimization of churn.

Thank you for the information.

> commit 66b47b4a9dad00e45c049d79966de9a3a1f4d337
> Author: Kees Cook 
> Date:   Mon Oct 13 15:51:57 2014 -0700
> 
> checkpatch: look for common misspellings
> 
> Check for misspellings, based on Debian's lintian list.  Several false
> positives were removed, and several additional words added that were
> common in the kernel:
> 
> backword backwords
> invalide valide
> recieves
> singed unsinged
> 
> While going back and fixing existing spelling mistakes isn't a high
> priority, it'd be nice to try to catch them before they hit the tree.

Re: report: scripts: checkpatch: Spell Checker Does Not Run with '-f'

[Federico Vaga]

On Thursday, February 14, 2019 3:44:55 PM CET Joe Perches wrote:
> On Thu, 2019-02-14 at 13:48 +0100, Federico Vaga wrote:
> > Hello,
> > 
> > Recently I have produce a couple of patches but I get different warnings
> > if I run checkpatch on the file (-f) or if I run it of a patch file. In
> > particular, the problem I found is with the spell checker which seems to
> > run only when the option '-f' is not used. I am wandering if there are
> > other similar cases.
> > 
> > I do not know Perl, so I cannot investigate more, but I have a practical
> > example. I have this simple patch applied on my tree that introduces a
> > spell
> > error:
> If you want spelling fixes on files you have to use --strict

Thanks

Is it a design choice to have different checks enabled with '-f'? 
 
> > From: Federico Vaga 
> > Date: Thu, 14 Feb 2019 13:29:39 +0100
> > Subject: [PATCH] script: checkpatch: buggy(?) output with -f option
> > 
> > Signed-off-by: Federico Vaga 
> > ---
> > 
> >  drivers/i2c/busses/i2c-ocores.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/i2c/busses/i2c-ocores.c
> > b/drivers/i2c/busses/i2c-ocores.c index b32d67c..f4deb90 100644
> > --- a/drivers/i2c/busses/i2c-ocores.c
> > +++ b/drivers/i2c/busses/i2c-ocores.c
> > @@ -301,7 +301,7 @@ static int ocores_poll_wait(struct ocores_i2c *i2c)
> > 
> > /* on going transfer */
> > mask = OCI2C_STAT_TIP;
> > /*
> > 
> > -* We wait for the data to be transferred (8bit),
> > +* We wait for the data to be transfered (8bit),
> > 
> >  * then we start polling on the ACK/NACK bit
> >  */
> > 
> > udelay((8 * 1000) / i2c->bus_clock_khz);

report: scripts: checkpatch: Spell Checker Does Not Run with '-f'

[Federico Vaga]

Hello,

Recently I have produce a couple of patches but I get different warnings if I 
run checkpatch on the file (-f) or if I run it of a patch file. In particular, 
the problem I found is with the spell checker which seems to run only when the 
option '-f' is not used. I am wandering if there are other similar cases.

I do not know Perl, so I cannot investigate more, but I have a practical 
example. I have this simple patch applied on my tree that introduces a spell 
error:


From: Federico Vaga 
Date: Thu, 14 Feb 2019 13:29:39 +0100
Subject: [PATCH] script: checkpatch: buggy(?) output with -f option

Signed-off-by: Federico Vaga 
---
 drivers/i2c/busses/i2c-ocores.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index b32d67c..f4deb90 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -301,7 +301,7 @@ static int ocores_poll_wait(struct ocores_i2c *i2c)
/* on going transfer */
mask = OCI2C_STAT_TIP;
/*
-* We wait for the data to be transferred (8bit),
+* We wait for the data to be transfered (8bit),
 * then we start polling on the ACK/NACK bit
 */
udelay((8 * 1000) / i2c->bus_clock_khz);
-- 
2.15.0


And here the outputs from checkpatch

- ON FILE 
./script/checkpatch.pl -f drivers/i2c/busses/i2c-ocores.c

total: 0 errors, 0 warnings, 765 lines checked

drivers/i2c/busses/i2c-ocores.c has no obvious style problems and is ready for 
submission.
-- ON PATCH ---
./script/checkpatch.pl 0001-script-checkpatch-buggy-output-with-f-option.patch

WARNING: Missing commit description - Add an appropriate one

WARNING: 'transfered' may be misspelled - perhaps 'transferred'?
#20: FILE: drivers/i2c/busses/i2c-ocores.c:304:
+* We wait for the data to be transfered (8bit),

total: 0 errors, 2 warnings, 8 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
  mechanically convert to the typical style using --fix or --fix-inplace.

0001-script-checkpatch-buggy-output-with-f-option.patch has style problems, 
please review.

NOTE: If any of the errors are false positives, please report
  them to the maintainer, see CHECKPATCH in MAINTAINERS.

-

[PATCH v7 0/5] i2c: ocores: improvements

[Federico Vaga]

This patch set provides improvements to the i2c-ocore driver.

[V6 -> V7]
- restore accidentally removed 'reviewed-by' tags in changelog

[V5 -> V6]
- remove redundant code introduced in V5 (double read control register)

[V4 -> V5]
- deterministic status of IEN bit in register "CONTROL" at the end of
  ocores_init()
- more style fixes

[V3 -> V4]
- add reviews-by/tested-by
- add comment to justify the formula in
udelay((8 * 1000) / i2c->bus_clock_khz);

[V2 -> V3]
- fix particular error condition on platform_get_irq(). Copied from
  https://patchwork.ozlabs.org/patch/1038409/

[V1 -> V2]
- replaced usleep_range() with udelay() so that the polling version can be
  used in atomic context.
- added dedicated patch for minor style issues
- fixed delay computation
- use spin_lock_irqsave(), instead of spin_trylock_irqsave(). IACK is always
  necessary and a trylock would generate an extra interrupt for nothing
- make the driver ready for an eventual master_xfer_irqless()

[PATCH v7 5/5] i2c: ocores: checkpatch fixes

[Federico Vaga]

Miscellaneous style fixes from checkpatch

Signed-off-by: Federico Vaga 
Reviewed-by: Andrew Lunn 
---
 drivers/i2c/busses/i2c-ocores.c | 29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 78085a8..b32d67c 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -179,8 +179,9 @@ static void ocores_process(struct ocores_i2c *i2c, u8 stat)
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
goto out;
}
-   } else
+   } else {
msg->buf[i2c->pos++] = oc_getreg(i2c, OCI2C_DATA);
+   }
 
/* end of msg? */
if (i2c->pos == msg->len) {
@@ -197,11 +198,11 @@ static void ocores_process(struct ocores_i2c *i2c, u8 
stat)
i2c->state = STATE_START;
 
oc_setreg(i2c, OCI2C_DATA, addr);
-   oc_setreg(i2c, OCI2C_CMD,  OCI2C_CMD_START);
+   oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_START);
goto out;
-   } else
-   i2c->state = (msg->flags & I2C_M_RD)
-   ? STATE_READ : STATE_WRITE;
+   }
+   i2c->state = (msg->flags & I2C_M_RD)
+   ? STATE_READ : STATE_WRITE;
} else {
i2c->state = STATE_DONE;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
@@ -461,13 +462,16 @@ static const struct of_device_id ocores_i2c_match[] = {
 MODULE_DEVICE_TABLE(of, ocores_i2c_match);
 
 #ifdef CONFIG_OF
-/* Read and write functions for the GRLIB port of the controller. Registers are
+/*
+ * Read and write functions for the GRLIB port of the controller. Registers are
  * 32-bit big endian and the PRELOW and PREHIGH registers are merged into one
- * register. The subsequent registers has their offset decreased accordingly. 
*/
+ * register. The subsequent registers have their offsets decreased accordingly.
+ */
 static u8 oc_getreg_grlib(struct ocores_i2c *i2c, int reg)
 {
u32 rd;
int rreg = reg;
+
if (reg != OCI2C_PRELOW)
rreg--;
rd = ioread32be(i2c->base + (rreg << i2c->reg_shift));
@@ -481,6 +485,7 @@ static void oc_setreg_grlib(struct ocores_i2c *i2c, int 
reg, u8 value)
 {
u32 curr, wr;
int rreg = reg;
+
if (reg != OCI2C_PRELOW)
rreg--;
if (reg == OCI2C_PRELOW || reg == OCI2C_PREHIGH) {
@@ -569,7 +574,7 @@ static int ocores_i2c_of_probe(struct platform_device *pdev,
return 0;
 }
 #else
-#define ocores_i2c_of_probe(pdev,i2c) -ENODEV
+#define ocores_i2c_of_probe(pdev, i2c) -ENODEV
 #endif
 
 static int ocores_i2c_probe(struct platform_device *pdev)
@@ -686,10 +691,11 @@ err_clk:
 static int ocores_i2c_remove(struct platform_device *pdev)
 {
struct ocores_i2c *i2c = platform_get_drvdata(pdev);
+   u8 ctrl = oc_getreg(i2c, OCI2C_CONTROL);
 
/* disable i2c logic */
-   oc_setreg(i2c, OCI2C_CONTROL, oc_getreg(i2c, OCI2C_CONTROL)
- & ~(OCI2C_CTRL_EN|OCI2C_CTRL_IEN));
+   ctrl &= ~(OCI2C_CTRL_EN | OCI2C_CTRL_IEN);
+   oc_setreg(i2c, OCI2C_CONTROL, ctrl);
 
/* remove adapter & data */
i2c_del_adapter(>adap);
@@ -707,7 +713,8 @@ static int ocores_i2c_suspend(struct device *dev)
u8 ctrl = oc_getreg(i2c, OCI2C_CONTROL);
 
/* make sure the device is disabled */
-   oc_setreg(i2c, OCI2C_CONTROL, ctrl & ~(OCI2C_CTRL_EN|OCI2C_CTRL_IEN));
+   ctrl &= ~(OCI2C_CTRL_EN | OCI2C_CTRL_IEN);
+   oc_setreg(i2c, OCI2C_CONTROL, ctrl);
 
if (!IS_ERR(i2c->clk))
clk_disable_unprepare(i2c->clk);
-- 
2.15.0

[PATCH v7 3/5] i2c: ocores: add polling interface

[Federico Vaga]

This driver assumes that an interrupt line is always available for
the I2C master. This is not always the case and this patch adds support
for a polling version.

Report from Andrew Lunn:

  I did some timing tests for this. On my box, we request a udelay of
  80uS. The kernel actually delays for about 79uS. We then spin in
  ocores_wait() for an additional 10-11uS, which is 3 to 4 iterations.

  There are actually 9 bits on the wire, not 8, since there is an
  ACK/NACK bit after the actual data transfer. So i changed the delay to
  (9 * 1000) / i2c->bus_clock_khz. That resulted in ocores_wait() mostly
  not looping at all. But for reading an 4K AT24 EEPROM, it increased
  the read time by 10ms, from 424ms to 434ms. So we should probably keep
  with 8.

Signed-off-by: Federico Vaga 
Tested-by: Andrew Lunn 
---
 drivers/i2c/busses/i2c-ocores.c | 182 +++-
 1 file changed, 161 insertions(+), 21 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index fcc2558..5dea7b9 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -13,6 +13,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,6 +27,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#define OCORES_FLAG_POLL BIT(0)
 
 /**
  * @process_lock: protect I2C transfer process.
@@ -35,6 +39,7 @@ struct ocores_i2c {
void __iomem *base;
u32 reg_shift;
u32 reg_io_width;
+   unsigned long flags;
wait_queue_head_t wait;
struct i2c_adapter adap;
struct i2c_msg *msg;
@@ -246,10 +251,116 @@ static void ocores_process_timeout(struct ocores_i2c 
*i2c)
spin_unlock_irqrestore(>process_lock, flags);
 }
 
-static int ocores_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
+/**
+ * Wait until something change in a given register
+ * @i2c: ocores I2C device instance
+ * @reg: register to query
+ * @mask: bitmask to apply on register value
+ * @val: expected result
+ * @timeout: timeout in jiffies
+ *
+ * Timeout is necessary to avoid to stay here forever when the chip
+ * does not answer correctly.
+ *
+ * Return: 0 on success, -ETIMEDOUT on timeout
+ */
+static int ocores_wait(struct ocores_i2c *i2c,
+  int reg, u8 mask, u8 val,
+  const unsigned long timeout)
+{
+   unsigned long j;
+
+   j = jiffies + timeout;
+   while (1) {
+   u8 status = oc_getreg(i2c, reg);
+
+   if ((status & mask) == val)
+   break;
+
+   if (time_after(jiffies, j))
+   return -ETIMEDOUT;
+   }
+   return 0;
+}
+
+/**
+ * Wait until is possible to process some data
+ * @i2c: ocores I2C device instance
+ *
+ * Used when the device is in polling mode (interrupts disabled).
+ *
+ * Return: 0 on success, -ETIMEDOUT on timeout
+ */
+static int ocores_poll_wait(struct ocores_i2c *i2c)
+{
+   u8 mask;
+   int err;
+
+   if (i2c->state == STATE_DONE || i2c->state == STATE_ERROR) {
+   /* transfer is over */
+   mask = OCI2C_STAT_BUSY;
+   } else {
+   /* on going transfer */
+   mask = OCI2C_STAT_TIP;
+   /*
+* We wait for the data to be transferred (8bit),
+* then we start polling on the ACK/NACK bit
+*/
+   udelay((8 * 1000) / i2c->bus_clock_khz);
+   }
+
+   /*
+* once we are here we expect to get the expected result immediately
+* so if after 1ms we timeout then something is broken.
+*/
+   err = ocores_wait(i2c, OCI2C_STATUS, mask, 0, msecs_to_jiffies(1));
+   if (err)
+   dev_warn(i2c->adap.dev.parent,
+"%s: STATUS timeout, bit 0x%x did not clear in 1ms\n",
+__func__, mask);
+   return err;
+}
+
+/**
+ * It handles an IRQ-less transfer
+ * @i2c: ocores I2C device instance
+ *
+ * Even if IRQ are disabled, the I2C OpenCore IP behavior is exactly the same
+ * (only that IRQ are not produced). This means that we can re-use entirely
+ * ocores_isr(), we just add our polling code around it.
+ *
+ * It can run in atomic context
+ */
+static void ocores_process_polling(struct ocores_i2c *i2c)
+{
+   while (1) {
+   irqreturn_t ret;
+   int err;
+
+   err = ocores_poll_wait(i2c);
+   if (err) {
+   i2c->state = STATE_ERROR;
+   break; /* timeout */
+   }
+
+   ret = ocores_isr(-1, i2c);
+   if (ret == IRQ_NONE)
+   break; /* all messages have been transferred */
+   }
+}
+
+static int ocores_xfer_core(struct ocores_i2c *i2c,
+   struct i2c_msg *msgs, int num,
+   bool polling)
 {
-   struct ocor

[PATCH v7 4/5] i2c: ocores: add SPDX tag

[Federico Vaga]

It adds the SPDX tag and it removes the old text about the GPLv2.

Signed-off-by: Federico Vaga 
Reviewed-by: Andrew Lunn 
---
 drivers/i2c/busses/i2c-ocores.c  | 5 +
 include/linux/platform_data/i2c-ocores.h | 5 +
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 5dea7b9..78085a8 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * i2c-ocores.c: I2C bus driver for OpenCores I2C controller
  * (https://opencores.org/project/i2c/overview)
@@ -6,10 +7,6 @@
  *
  * Support for the GRLIB port of the controller by
  * Andreas Larsson 
- *
- * This file is licensed under the terms of the GNU General Public License
- * version 2.  This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
  */
 
 #include 
diff --git a/include/linux/platform_data/i2c-ocores.h 
b/include/linux/platform_data/i2c-ocores.h
index 113d6b1..8c416ff 100644
--- a/include/linux/platform_data/i2c-ocores.h
+++ b/include/linux/platform_data/i2c-ocores.h
@@ -1,11 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
  * i2c-ocores.h - definitions for the i2c-ocores interface
  *
  * Peter Korsgaard 
- *
- * This file is licensed under the terms of the GNU General Public License
- * version 2.  This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
  */
 
 #ifndef _LINUX_I2C_OCORES_H
-- 
2.15.0

[PATCH v7 2/5] i2c: ocores: do not handle IRQ if IF is not set

[Federico Vaga]

If the Interrupt Flag (IF) is not set, we should not handle the IRQ:
- the line can be shared with other devices
- it can be a spurious interrupt

To avoid reading twice the status register, the ocores_process() function
expects it to be read by the caller.

Signed-off-by: Federico Vaga 
Acked-by: Peter Korsgaard 
Reviewed-by: Andrew Lunn 
---
 drivers/i2c/busses/i2c-ocores.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index aa85202..fcc2558 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -143,10 +143,9 @@ static inline u8 oc_getreg(struct ocores_i2c *i2c, int reg)
return i2c->getreg(i2c, reg);
 }
 
-static void ocores_process(struct ocores_i2c *i2c)
+static void ocores_process(struct ocores_i2c *i2c, u8 stat)
 {
struct i2c_msg *msg = i2c->msg;
-   u8 stat = oc_getreg(i2c, OCI2C_STATUS);
unsigned long flags;
 
/*
@@ -223,8 +222,12 @@ out:
 static irqreturn_t ocores_isr(int irq, void *dev_id)
 {
struct ocores_i2c *i2c = dev_id;
+   u8 stat = oc_getreg(i2c, OCI2C_STATUS);
+
+   if (!(stat & OCI2C_STAT_IF))
+   return IRQ_NONE;
 
-   ocores_process(i2c);
+   ocores_process(i2c, stat);
 
return IRQ_HANDLED;
 }
-- 
2.15.0

[PATCH v7 1/5] i2c: ocores: stop transfer on timeout

[Federico Vaga]

Detecting a timeout is ok, but we also need to assert a STOP command on
the bus in order to prevent it from generating interrupts when there are
no on going transfers.

Example: very long transmission.

1. ocores_xfer: START a transfer
2. ocores_isr : handle byte by byte the transfer
3. ocores_xfer: goes in timeout [[bugfix here]]
4. ocores_xfer: return to I2C subsystem and to the I2C driver
5. I2C driver : it may clean up the i2c_msg memory
6. ocores_isr : receives another interrupt (pending bytes to be
transferred) but the i2c_msg memory is invalid now

So, since the transfer was too long, we have to detect the timeout and
STOP the transfer.

Another point is that we have a critical region here. When handling the
timeout condition we may have a running IRQ handler. For this reason I
introduce a spinlock.

In order to make easier to understan locking I have:
- added a new function to handle timeout
- modified the current ocores_process() function in order to be protected
  by the new spinlock
Like this it is obvious at first sight that this locking serializes
the execution of ocores_process() and ocores_process_timeout()

Signed-off-by: Federico Vaga 
Reviewed-by: Andrew Lunn 
---
 drivers/i2c/busses/i2c-ocores.c | 54 ++---
 1 file changed, 45 insertions(+), 9 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 87f9caa..aa85202 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -25,7 +25,12 @@
 #include 
 #include 
 #include 
+#include 
 
+/**
+ * @process_lock: protect I2C transfer process.
+ * ocores_process() and ocores_process_timeout() can't run in parallel.
+ */
 struct ocores_i2c {
void __iomem *base;
u32 reg_shift;
@@ -36,6 +41,7 @@ struct ocores_i2c {
int pos;
int nmsgs;
int state; /* see STATE_ */
+   spinlock_t process_lock;
struct clk *clk;
int ip_clock_khz;
int bus_clock_khz;
@@ -141,19 +147,26 @@ static void ocores_process(struct ocores_i2c *i2c)
 {
struct i2c_msg *msg = i2c->msg;
u8 stat = oc_getreg(i2c, OCI2C_STATUS);
+   unsigned long flags;
+
+   /*
+* If we spin here is because we are in timeout, so we are going
+* to be in STATE_ERROR. See ocores_process_timeout()
+*/
+   spin_lock_irqsave(>process_lock, flags);
 
if ((i2c->state == STATE_DONE) || (i2c->state == STATE_ERROR)) {
/* stop has been sent */
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_IACK);
wake_up(>wait);
-   return;
+   goto out;
}
 
/* error? */
if (stat & OCI2C_STAT_ARBLOST) {
i2c->state = STATE_ERROR;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
-   return;
+   goto out;
}
 
if ((i2c->state == STATE_START) || (i2c->state == STATE_WRITE)) {
@@ -163,7 +176,7 @@ static void ocores_process(struct ocores_i2c *i2c)
if (stat & OCI2C_STAT_NACK) {
i2c->state = STATE_ERROR;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
-   return;
+   goto out;
}
} else
msg->buf[i2c->pos++] = oc_getreg(i2c, OCI2C_DATA);
@@ -184,14 +197,14 @@ static void ocores_process(struct ocores_i2c *i2c)
 
oc_setreg(i2c, OCI2C_DATA, addr);
oc_setreg(i2c, OCI2C_CMD,  OCI2C_CMD_START);
-   return;
+   goto out;
} else
i2c->state = (msg->flags & I2C_M_RD)
? STATE_READ : STATE_WRITE;
} else {
i2c->state = STATE_DONE;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
-   return;
+   goto out;
}
}
 
@@ -202,6 +215,9 @@ static void ocores_process(struct ocores_i2c *i2c)
oc_setreg(i2c, OCI2C_DATA, msg->buf[i2c->pos++]);
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_WRITE);
}
+
+out:
+   spin_unlock_irqrestore(>process_lock, flags);
 }
 
 static irqreturn_t ocores_isr(int irq, void *dev_id)
@@ -213,9 +229,24 @@ static irqreturn_t ocores_isr(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+/**
+ * Process timeout event
+ * @i2c: ocores I2C device instance
+ */
+static void ocores_process_timeout(struct ocores_i2c *i2c)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>process_lock, flags);
+   i2c->state = STATE_ERROR;
+   oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
+   spin_unlock_irqrestore(>process_lock, flags);
+}
+
 static int ocores_xfer(st

Re: [PATCH v6 0/5] i2c: ocores: improvements

[Federico Vaga]

On Thursday, February 14, 2019 4:07:33 AM CET Andrew Lunn wrote:
> On Mon, Feb 11, 2019 at 05:49:08PM +0100, Federico Vaga wrote:
> > This patch set provides improvements to the i2c-ocore driver.
> > 
> > [V5 -> V6]
> > - remove redundant code introduced in V5 (double read control register)
> > 
> > [V4 -> V5]
> > - deterministic status of IEN bit in register "CONTROL" at the end of
> > 
> >   ocores_init()
> > 
> > - more style fixes
> > 
> > [V3 -> V4]
> > - add reviews-by/tested-by
> > - add comment to justify the formula in
> > 
> > udelay((8 * 1000) / i2c->bus_clock_khz);
> 
> Hi Federico
> 
> It looks like all the reviewed-by: tags disappeared from v5.
> 
> Can you add them back again, and then we can probably merge this
> patchset.

v7 is coming (@wolfram) with SPDX tag in the header file

>   Thanks
>   Andrew

Re: [PATCH v6 4/5] i2c: ocores: add SPDX tag

[Federico Vaga]

On Monday, February 11, 2019 5:54:54 PM CET Wolfram Sang wrote:
> On Mon, Feb 11, 2019 at 05:49:12PM +0100, Federico Vaga wrote:
> > It adds the SPDX tag and it removes the old text about the GPLv2.
> > 
> > Signed-off-by: Federico Vaga 
> 
> I can convert the platform_data header to SPDX again. No need to resend
> because of that.

Sorry, and thanks

[PATCH v6 2/5] i2c: ocores: do not handle IRQ if IF is not set

[Federico Vaga]

If the Interrupt Flag (IF) is not set, we should not handle the IRQ:
- the line can be shared with other devices
- it can be a spurious interrupt

To avoid reading twice the status register, the ocores_process() function
expects it to be read by the caller.

Signed-off-by: Federico Vaga 
Acked-by: Peter Korsgaard 
---
 drivers/i2c/busses/i2c-ocores.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index aa85202..fcc2558 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -143,10 +143,9 @@ static inline u8 oc_getreg(struct ocores_i2c *i2c, int reg)
return i2c->getreg(i2c, reg);
 }
 
-static void ocores_process(struct ocores_i2c *i2c)
+static void ocores_process(struct ocores_i2c *i2c, u8 stat)
 {
struct i2c_msg *msg = i2c->msg;
-   u8 stat = oc_getreg(i2c, OCI2C_STATUS);
unsigned long flags;
 
/*
@@ -223,8 +222,12 @@ out:
 static irqreturn_t ocores_isr(int irq, void *dev_id)
 {
struct ocores_i2c *i2c = dev_id;
+   u8 stat = oc_getreg(i2c, OCI2C_STATUS);
+
+   if (!(stat & OCI2C_STAT_IF))
+   return IRQ_NONE;
 
-   ocores_process(i2c);
+   ocores_process(i2c, stat);
 
return IRQ_HANDLED;
 }
-- 
2.15.0

[PATCH v6 5/5] i2c: ocores: checkpatch fixes

[Federico Vaga]

Miscellaneous style fixes from checkpatch

Signed-off-by: Federico Vaga 
---
 drivers/i2c/busses/i2c-ocores.c | 29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 78085a8..b32d67c 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -179,8 +179,9 @@ static void ocores_process(struct ocores_i2c *i2c, u8 stat)
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
goto out;
}
-   } else
+   } else {
msg->buf[i2c->pos++] = oc_getreg(i2c, OCI2C_DATA);
+   }
 
/* end of msg? */
if (i2c->pos == msg->len) {
@@ -197,11 +198,11 @@ static void ocores_process(struct ocores_i2c *i2c, u8 
stat)
i2c->state = STATE_START;
 
oc_setreg(i2c, OCI2C_DATA, addr);
-   oc_setreg(i2c, OCI2C_CMD,  OCI2C_CMD_START);
+   oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_START);
goto out;
-   } else
-   i2c->state = (msg->flags & I2C_M_RD)
-   ? STATE_READ : STATE_WRITE;
+   }
+   i2c->state = (msg->flags & I2C_M_RD)
+   ? STATE_READ : STATE_WRITE;
} else {
i2c->state = STATE_DONE;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
@@ -461,13 +462,16 @@ static const struct of_device_id ocores_i2c_match[] = {
 MODULE_DEVICE_TABLE(of, ocores_i2c_match);
 
 #ifdef CONFIG_OF
-/* Read and write functions for the GRLIB port of the controller. Registers are
+/*
+ * Read and write functions for the GRLIB port of the controller. Registers are
  * 32-bit big endian and the PRELOW and PREHIGH registers are merged into one
- * register. The subsequent registers has their offset decreased accordingly. 
*/
+ * register. The subsequent registers have their offsets decreased accordingly.
+ */
 static u8 oc_getreg_grlib(struct ocores_i2c *i2c, int reg)
 {
u32 rd;
int rreg = reg;
+
if (reg != OCI2C_PRELOW)
rreg--;
rd = ioread32be(i2c->base + (rreg << i2c->reg_shift));
@@ -481,6 +485,7 @@ static void oc_setreg_grlib(struct ocores_i2c *i2c, int 
reg, u8 value)
 {
u32 curr, wr;
int rreg = reg;
+
if (reg != OCI2C_PRELOW)
rreg--;
if (reg == OCI2C_PRELOW || reg == OCI2C_PREHIGH) {
@@ -569,7 +574,7 @@ static int ocores_i2c_of_probe(struct platform_device *pdev,
return 0;
 }
 #else
-#define ocores_i2c_of_probe(pdev,i2c) -ENODEV
+#define ocores_i2c_of_probe(pdev, i2c) -ENODEV
 #endif
 
 static int ocores_i2c_probe(struct platform_device *pdev)
@@ -686,10 +691,11 @@ err_clk:
 static int ocores_i2c_remove(struct platform_device *pdev)
 {
struct ocores_i2c *i2c = platform_get_drvdata(pdev);
+   u8 ctrl = oc_getreg(i2c, OCI2C_CONTROL);
 
/* disable i2c logic */
-   oc_setreg(i2c, OCI2C_CONTROL, oc_getreg(i2c, OCI2C_CONTROL)
- & ~(OCI2C_CTRL_EN|OCI2C_CTRL_IEN));
+   ctrl &= ~(OCI2C_CTRL_EN | OCI2C_CTRL_IEN);
+   oc_setreg(i2c, OCI2C_CONTROL, ctrl);
 
/* remove adapter & data */
i2c_del_adapter(>adap);
@@ -707,7 +713,8 @@ static int ocores_i2c_suspend(struct device *dev)
u8 ctrl = oc_getreg(i2c, OCI2C_CONTROL);
 
/* make sure the device is disabled */
-   oc_setreg(i2c, OCI2C_CONTROL, ctrl & ~(OCI2C_CTRL_EN|OCI2C_CTRL_IEN));
+   ctrl &= ~(OCI2C_CTRL_EN | OCI2C_CTRL_IEN);
+   oc_setreg(i2c, OCI2C_CONTROL, ctrl);
 
if (!IS_ERR(i2c->clk))
clk_disable_unprepare(i2c->clk);
-- 
2.15.0

[PATCH v6 1/5] i2c: ocores: stop transfer on timeout

[Federico Vaga]

Detecting a timeout is ok, but we also need to assert a STOP command on
the bus in order to prevent it from generating interrupts when there are
no on going transfers.

Example: very long transmission.

1. ocores_xfer: START a transfer
2. ocores_isr : handle byte by byte the transfer
3. ocores_xfer: goes in timeout [[bugfix here]]
4. ocores_xfer: return to I2C subsystem and to the I2C driver
5. I2C driver : it may clean up the i2c_msg memory
6. ocores_isr : receives another interrupt (pending bytes to be
transferred) but the i2c_msg memory is invalid now

So, since the transfer was too long, we have to detect the timeout and
STOP the transfer.

Another point is that we have a critical region here. When handling the
timeout condition we may have a running IRQ handler. For this reason I
introduce a spinlock.

In order to make easier to understan locking I have:
- added a new function to handle timeout
- modified the current ocores_process() function in order to be protected
  by the new spinlock
Like this it is obvious at first sight that this locking serializes
the execution of ocores_process() and ocores_process_timeout()

Signed-off-by: Federico Vaga 
---
 drivers/i2c/busses/i2c-ocores.c | 54 ++---
 1 file changed, 45 insertions(+), 9 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 87f9caa..aa85202 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -25,7 +25,12 @@
 #include 
 #include 
 #include 
+#include 
 
+/**
+ * @process_lock: protect I2C transfer process.
+ * ocores_process() and ocores_process_timeout() can't run in parallel.
+ */
 struct ocores_i2c {
void __iomem *base;
u32 reg_shift;
@@ -36,6 +41,7 @@ struct ocores_i2c {
int pos;
int nmsgs;
int state; /* see STATE_ */
+   spinlock_t process_lock;
struct clk *clk;
int ip_clock_khz;
int bus_clock_khz;
@@ -141,19 +147,26 @@ static void ocores_process(struct ocores_i2c *i2c)
 {
struct i2c_msg *msg = i2c->msg;
u8 stat = oc_getreg(i2c, OCI2C_STATUS);
+   unsigned long flags;
+
+   /*
+* If we spin here is because we are in timeout, so we are going
+* to be in STATE_ERROR. See ocores_process_timeout()
+*/
+   spin_lock_irqsave(>process_lock, flags);
 
if ((i2c->state == STATE_DONE) || (i2c->state == STATE_ERROR)) {
/* stop has been sent */
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_IACK);
wake_up(>wait);
-   return;
+   goto out;
}
 
/* error? */
if (stat & OCI2C_STAT_ARBLOST) {
i2c->state = STATE_ERROR;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
-   return;
+   goto out;
}
 
if ((i2c->state == STATE_START) || (i2c->state == STATE_WRITE)) {
@@ -163,7 +176,7 @@ static void ocores_process(struct ocores_i2c *i2c)
if (stat & OCI2C_STAT_NACK) {
i2c->state = STATE_ERROR;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
-   return;
+   goto out;
}
} else
msg->buf[i2c->pos++] = oc_getreg(i2c, OCI2C_DATA);
@@ -184,14 +197,14 @@ static void ocores_process(struct ocores_i2c *i2c)
 
oc_setreg(i2c, OCI2C_DATA, addr);
oc_setreg(i2c, OCI2C_CMD,  OCI2C_CMD_START);
-   return;
+   goto out;
} else
i2c->state = (msg->flags & I2C_M_RD)
? STATE_READ : STATE_WRITE;
} else {
i2c->state = STATE_DONE;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
-   return;
+   goto out;
}
}
 
@@ -202,6 +215,9 @@ static void ocores_process(struct ocores_i2c *i2c)
oc_setreg(i2c, OCI2C_DATA, msg->buf[i2c->pos++]);
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_WRITE);
}
+
+out:
+   spin_unlock_irqrestore(>process_lock, flags);
 }
 
 static irqreturn_t ocores_isr(int irq, void *dev_id)
@@ -213,9 +229,24 @@ static irqreturn_t ocores_isr(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+/**
+ * Process timeout event
+ * @i2c: ocores I2C device instance
+ */
+static void ocores_process_timeout(struct ocores_i2c *i2c)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>process_lock, flags);
+   i2c->state = STATE_ERROR;
+   oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
+   spin_unlock_irqrestore(>process_lock, flags);
+}
+
 static int ocores_xfer(struct i2c_adapter

[PATCH v6 3/5] i2c: ocores: add polling interface

[Federico Vaga]

This driver assumes that an interrupt line is always available for
the I2C master. This is not always the case and this patch adds support
for a polling version.

Report from Andrew Lunn:

  I did some timing tests for this. On my box, we request a udelay of
  80uS. The kernel actually delays for about 79uS. We then spin in
  ocores_wait() for an additional 10-11uS, which is 3 to 4 iterations.

  There are actually 9 bits on the wire, not 8, since there is an
  ACK/NACK bit after the actual data transfer. So i changed the delay to
  (9 * 1000) / i2c->bus_clock_khz. That resulted in ocores_wait() mostly
  not looping at all. But for reading an 4K AT24 EEPROM, it increased
  the read time by 10ms, from 424ms to 434ms. So we should probably keep
  with 8.

Signed-off-by: Federico Vaga 
Tested-by: Andrew Lunn 
---
 drivers/i2c/busses/i2c-ocores.c | 182 +++-
 1 file changed, 161 insertions(+), 21 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index fcc2558..5dea7b9 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -13,6 +13,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,6 +27,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#define OCORES_FLAG_POLL BIT(0)
 
 /**
  * @process_lock: protect I2C transfer process.
@@ -35,6 +39,7 @@ struct ocores_i2c {
void __iomem *base;
u32 reg_shift;
u32 reg_io_width;
+   unsigned long flags;
wait_queue_head_t wait;
struct i2c_adapter adap;
struct i2c_msg *msg;
@@ -246,10 +251,116 @@ static void ocores_process_timeout(struct ocores_i2c 
*i2c)
spin_unlock_irqrestore(>process_lock, flags);
 }
 
-static int ocores_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
+/**
+ * Wait until something change in a given register
+ * @i2c: ocores I2C device instance
+ * @reg: register to query
+ * @mask: bitmask to apply on register value
+ * @val: expected result
+ * @timeout: timeout in jiffies
+ *
+ * Timeout is necessary to avoid to stay here forever when the chip
+ * does not answer correctly.
+ *
+ * Return: 0 on success, -ETIMEDOUT on timeout
+ */
+static int ocores_wait(struct ocores_i2c *i2c,
+  int reg, u8 mask, u8 val,
+  const unsigned long timeout)
+{
+   unsigned long j;
+
+   j = jiffies + timeout;
+   while (1) {
+   u8 status = oc_getreg(i2c, reg);
+
+   if ((status & mask) == val)
+   break;
+
+   if (time_after(jiffies, j))
+   return -ETIMEDOUT;
+   }
+   return 0;
+}
+
+/**
+ * Wait until is possible to process some data
+ * @i2c: ocores I2C device instance
+ *
+ * Used when the device is in polling mode (interrupts disabled).
+ *
+ * Return: 0 on success, -ETIMEDOUT on timeout
+ */
+static int ocores_poll_wait(struct ocores_i2c *i2c)
+{
+   u8 mask;
+   int err;
+
+   if (i2c->state == STATE_DONE || i2c->state == STATE_ERROR) {
+   /* transfer is over */
+   mask = OCI2C_STAT_BUSY;
+   } else {
+   /* on going transfer */
+   mask = OCI2C_STAT_TIP;
+   /*
+* We wait for the data to be transferred (8bit),
+* then we start polling on the ACK/NACK bit
+*/
+   udelay((8 * 1000) / i2c->bus_clock_khz);
+   }
+
+   /*
+* once we are here we expect to get the expected result immediately
+* so if after 1ms we timeout then something is broken.
+*/
+   err = ocores_wait(i2c, OCI2C_STATUS, mask, 0, msecs_to_jiffies(1));
+   if (err)
+   dev_warn(i2c->adap.dev.parent,
+"%s: STATUS timeout, bit 0x%x did not clear in 1ms\n",
+__func__, mask);
+   return err;
+}
+
+/**
+ * It handles an IRQ-less transfer
+ * @i2c: ocores I2C device instance
+ *
+ * Even if IRQ are disabled, the I2C OpenCore IP behavior is exactly the same
+ * (only that IRQ are not produced). This means that we can re-use entirely
+ * ocores_isr(), we just add our polling code around it.
+ *
+ * It can run in atomic context
+ */
+static void ocores_process_polling(struct ocores_i2c *i2c)
+{
+   while (1) {
+   irqreturn_t ret;
+   int err;
+
+   err = ocores_poll_wait(i2c);
+   if (err) {
+   i2c->state = STATE_ERROR;
+   break; /* timeout */
+   }
+
+   ret = ocores_isr(-1, i2c);
+   if (ret == IRQ_NONE)
+   break; /* all messages have been transferred */
+   }
+}
+
+static int ocores_xfer_core(struct ocores_i2c *i2c,
+   struct i2c_msg *msgs, int num,
+   bool polling)
 {
-   struct ocor

[PATCH v6 4/5] i2c: ocores: add SPDX tag

[Federico Vaga]

It adds the SPDX tag and it removes the old text about the GPLv2.

Signed-off-by: Federico Vaga 
---
 drivers/i2c/busses/i2c-ocores.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 5dea7b9..78085a8 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * i2c-ocores.c: I2C bus driver for OpenCores I2C controller
  * (https://opencores.org/project/i2c/overview)
@@ -6,10 +7,6 @@
  *
  * Support for the GRLIB port of the controller by
  * Andreas Larsson 
- *
- * This file is licensed under the terms of the GNU General Public License
- * version 2.  This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
  */
 
 #include 
-- 
2.15.0

[PATCH v6 0/5] i2c: ocores: improvements

[Federico Vaga]

This patch set provides improvements to the i2c-ocore driver.

[V5 -> V6]
- remove redundant code introduced in V5 (double read control register)

[V4 -> V5]
- deterministic status of IEN bit in register "CONTROL" at the end of
  ocores_init()
- more style fixes

[V3 -> V4]
- add reviews-by/tested-by
- add comment to justify the formula in
udelay((8 * 1000) / i2c->bus_clock_khz);

[V2 -> V3]
- fix particular error condition on platform_get_irq(). Copied from
  https://patchwork.ozlabs.org/patch/1038409/

[V1 -> V2]
- replaced usleep_range() with udelay() so that the polling version can be
  used in atomic context.
- added dedicated patch for minor style issues
- fixed delay computation
- use spin_lock_irqsave(), instead of spin_trylock_irqsave(). IACK is always
  necessary and a trylock would generate an extra interrupt for nothing
- make the driver ready for an eventual master_xfer_irqless()

Re: [PATCH v5 5/5] i2c:ocores: checkpatch fixes

[Federico Vaga]

On Monday, February 11, 2019 5:12:23 PM CET Peter Rosin wrote:
> On 2019-02-11 17:05, Federico Vaga wrote:
> 
> > Miscellaneous style fixes from checkpatch
> > 
> > Signed-off-by: Federico Vaga 
> > ---
> > 
> >  drivers/i2c/busses/i2c-ocores.c | 30 +++---
> >  1 file changed, 19 insertions(+), 11 deletions(-)
> > 
> > 
> > diff --git a/drivers/i2c/busses/i2c-ocores.c
> > b/drivers/i2c/busses/i2c-ocores.c
 index 78085a8..54b2156 100644
> > --- a/drivers/i2c/busses/i2c-ocores.c
> > +++ b/drivers/i2c/busses/i2c-ocores.c
> > @@ -179,8 +179,9 @@ static void ocores_process(struct ocores_i2c *i2c, u8
> > stat)
> 
> > oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
> > goto out;
> > 
> > }
> > 
> > -   } else
> > +   } else {
> > 
> > msg->buf[i2c->pos++] = oc_getreg(i2c, OCI2C_DATA);
> > 
> > +   }
> > 
> >  
> >  
> > /* end of msg? */
> > if (i2c->pos == msg->len) {
> > 
> > @@ -197,11 +198,11 @@ static void ocores_process(struct ocores_i2c *i2c,
> > u8 stat)
> 
> > i2c->state = STATE_START;
> >  
> >  
> >  
> > oc_setreg(i2c, OCI2C_DATA, addr);
> > 
> > -   oc_setreg(i2c, OCI2C_CMD,  OCI2C_CMD_START);
> > +   oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_START);
> > 
> > goto out;
> > 
> > -   } else
> > -   i2c->state = (msg->flags & I2C_M_RD)
> > -   ? STATE_READ : STATE_WRITE;
> > +   }
> > +   i2c->state = (msg->flags & I2C_M_RD)
> > +   ? STATE_READ : STATE_WRITE;
> > 
> > } else {
> > 
> > i2c->state = STATE_DONE;
> > oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
> > 
> > @@ -461,13 +462,16 @@ static const struct of_device_id ocores_i2c_match[]
> > = {
> 
> >  MODULE_DEVICE_TABLE(of, ocores_i2c_match);
> >  
> >  #ifdef CONFIG_OF
> > 
> > -/* Read and write functions for the GRLIB port of the controller.
> > Registers are
 +/*
> > + * Read and write functions for the GRLIB port of the controller.
> > Registers are
> 
> >   * 32-bit big endian and the PRELOW and PREHIGH registers are merged into
> >   one
> 
> > - * register. The subsequent registers has their offset decreased
> > accordingly. */
 + * register. The subsequent registers have their
> > offsets decreased accordingly. + */
> > 
> >  static u8 oc_getreg_grlib(struct ocores_i2c *i2c, int reg)
> >  {
> >  
> > u32 rd;
> > int rreg = reg;
> > 
> > +
> > 
> > if (reg != OCI2C_PRELOW)
> > 
> > rreg--;
> > 
> > rd = ioread32be(i2c->base + (rreg << i2c->reg_shift));
> > 
> > @@ -481,6 +485,7 @@ static void oc_setreg_grlib(struct ocores_i2c *i2c,
> > int reg, u8 value)
> 
> >  {
> >  
> > u32 curr, wr;
> > int rreg = reg;
> > 
> > +
> > 
> > if (reg != OCI2C_PRELOW)
> > 
> > rreg--;
> > 
> > if (reg == OCI2C_PRELOW || reg == OCI2C_PREHIGH) {
> > 
> > @@ -569,7 +574,7 @@ static int ocores_i2c_of_probe(struct platform_device
> > *pdev,
> 
> > return 0;
> >  
> >  }
> >  #else
> > 
> > -#define ocores_i2c_of_probe(pdev,i2c) -ENODEV
> > +#define ocores_i2c_of_probe(pdev, i2c) -ENODEV
> > 
> >  #endif
> >  
> >  static int ocores_i2c_probe(struct platform_device *pdev)
> > 
> > @@ -686,10 +691,11 @@ err_clk:
> > 
> >  static int ocores_i2c_remove(struct platform_device *pdev)
> >  {
> >  
> > struct ocores_i2c *i2c = platform_get_drvdata(pdev);
> > 
> > +   u8 ctrl = oc_getreg(i2c, OCI2C_CONTROL);
> > 
> >  
> >  
> > /* disable i2c logic */
> > 
> > -   oc_setreg(i2c, OCI2C_CONTROL, oc_getreg(i2c, OCI2C_CONTROL)
> > - & ~(OCI2C_CTRL_EN|OCI2C_CTRL_IEN));
> > +   ctrl &= ~(OCI2C_CTRL_EN | OCI2C_CTRL_IEN);
> > +   oc_setreg(i2c, OCI2C_CONTROL, ctrl);
> > 
> >  
> >  
> > /* remove adapter & data */
> > i2c_del_adapter(>adap);
> > 
> > @@ -707,7 +713,9 @@ static int ocores_i2c_suspend(struct device *dev)
> > 
> > u8 ctrl = oc_getreg(i2c, OCI2C_CONTROL);
> >  
> >  
> >  
> > /* make sure the device is disabled */
> > 
> > -   oc_setreg(i2c, OCI2C_CONTROL, ctrl & ~(OCI2C_CTRL_EN|OCI2C_CTRL_IEN));
> > +   ctrl = oc_getreg(i2c, OCI2C_CONTROL);
> 
> 
> There's a pointless double oc_getreg(i2c, OCI2C_CONTROL).

Very sorry for the waste of time for such a stupid copy error.
V6 is coming.
 
> Cheers,
> Peter
> 
> 
> > +   ctrl &= ~(OCI2C_CTRL_EN | OCI2C_CTRL_IEN);
> > +   oc_setreg(i2c, OCI2C_CONTROL, ctrl);
> > 
> >  
> >  
> > if (!IS_ERR(i2c->clk))
> > 
> > clk_disable_unprepare(i2c->clk);
> > 
> > 
> 
> 

[PATCH v5 0/5] i2c:ocores: improvements

[Federico Vaga]

This patch set provides improvements to the i2c-ocore driver.

[V4 -> V5]
- deterministic status of IEN bit in register "CONTROL" at the end of
  ocores_init()
- more style fixes

[V3 -> V4]
- add reviews-by/tested-by
- add comment to justify the formula in
udelay((8 * 1000) / i2c->bus_clock_khz);

[V2 -> V3]
- fix particular error condition on platform_get_irq(). Copied from
  https://patchwork.ozlabs.org/patch/1038409/

[V1 -> V2]
- replaced usleep_range() with udelay() so that the polling version can be
  used in atomic context.
- added dedicated patch for minor style issues
- fixed delay computation
- use spin_lock_irqsave(), instead of spin_trylock_irqsave(). IACK is always
  necessary and a trylock would generate an extra interrupt for nothing
- make the driver ready for an eventual master_xfer_irqless()

[PATCH v5 1/5] i2c:ocores: stop transfer on timeout

[Federico Vaga]

Detecting a timeout is ok, but we also need to assert a STOP command on
the bus in order to prevent it from generating interrupts when there are
no on going transfers.

Example: very long transmission.

1. ocores_xfer: START a transfer
2. ocores_isr : handle byte by byte the transfer
3. ocores_xfer: goes in timeout [[bugfix here]]
4. ocores_xfer: return to I2C subsystem and to the I2C driver
5. I2C driver : it may clean up the i2c_msg memory
6. ocores_isr : receives another interrupt (pending bytes to be
transferred) but the i2c_msg memory is invalid now

So, since the transfer was too long, we have to detect the timeout and
STOP the transfer.

Another point is that we have a critical region here. When handling the
timeout condition we may have a running IRQ handler. For this reason I
introduce a spinlock.

In order to make easier to understan locking I have:
- added a new function to handle timeout
- modified the current ocores_process() function in order to be protected
  by the new spinlock
Like this it is obvious at first sight that this locking serializes
the execution of ocores_process() and ocores_process_timeout()

Signed-off-by: Federico Vaga 
---
 drivers/i2c/busses/i2c-ocores.c | 54 ++---
 1 file changed, 45 insertions(+), 9 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 87f9caa..aa85202 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -25,7 +25,12 @@
 #include 
 #include 
 #include 
+#include 
 
+/**
+ * @process_lock: protect I2C transfer process.
+ * ocores_process() and ocores_process_timeout() can't run in parallel.
+ */
 struct ocores_i2c {
void __iomem *base;
u32 reg_shift;
@@ -36,6 +41,7 @@ struct ocores_i2c {
int pos;
int nmsgs;
int state; /* see STATE_ */
+   spinlock_t process_lock;
struct clk *clk;
int ip_clock_khz;
int bus_clock_khz;
@@ -141,19 +147,26 @@ static void ocores_process(struct ocores_i2c *i2c)
 {
struct i2c_msg *msg = i2c->msg;
u8 stat = oc_getreg(i2c, OCI2C_STATUS);
+   unsigned long flags;
+
+   /*
+* If we spin here is because we are in timeout, so we are going
+* to be in STATE_ERROR. See ocores_process_timeout()
+*/
+   spin_lock_irqsave(>process_lock, flags);
 
if ((i2c->state == STATE_DONE) || (i2c->state == STATE_ERROR)) {
/* stop has been sent */
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_IACK);
wake_up(>wait);
-   return;
+   goto out;
}
 
/* error? */
if (stat & OCI2C_STAT_ARBLOST) {
i2c->state = STATE_ERROR;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
-   return;
+   goto out;
}
 
if ((i2c->state == STATE_START) || (i2c->state == STATE_WRITE)) {
@@ -163,7 +176,7 @@ static void ocores_process(struct ocores_i2c *i2c)
if (stat & OCI2C_STAT_NACK) {
i2c->state = STATE_ERROR;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
-   return;
+   goto out;
}
} else
msg->buf[i2c->pos++] = oc_getreg(i2c, OCI2C_DATA);
@@ -184,14 +197,14 @@ static void ocores_process(struct ocores_i2c *i2c)
 
oc_setreg(i2c, OCI2C_DATA, addr);
oc_setreg(i2c, OCI2C_CMD,  OCI2C_CMD_START);
-   return;
+   goto out;
} else
i2c->state = (msg->flags & I2C_M_RD)
? STATE_READ : STATE_WRITE;
} else {
i2c->state = STATE_DONE;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
-   return;
+   goto out;
}
}
 
@@ -202,6 +215,9 @@ static void ocores_process(struct ocores_i2c *i2c)
oc_setreg(i2c, OCI2C_DATA, msg->buf[i2c->pos++]);
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_WRITE);
}
+
+out:
+   spin_unlock_irqrestore(>process_lock, flags);
 }
 
 static irqreturn_t ocores_isr(int irq, void *dev_id)
@@ -213,9 +229,24 @@ static irqreturn_t ocores_isr(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+/**
+ * Process timeout event
+ * @i2c: ocores I2C device instance
+ */
+static void ocores_process_timeout(struct ocores_i2c *i2c)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>process_lock, flags);
+   i2c->state = STATE_ERROR;
+   oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
+   spin_unlock_irqrestore(>process_lock, flags);
+}
+
 static int ocores_xfer(struct i2c_adapter

[PATCH v5 3/5] i2c:ocores: add polling interface

[Federico Vaga]

This driver assumes that an interrupt line is always available for
the I2C master. This is not always the case and this patch adds support
for a polling version.

Report from Andrew Lunn:

  I did some timing tests for this. On my box, we request a udelay of
  80uS. The kernel actually delays for about 79uS. We then spin in
  ocores_wait() for an additional 10-11uS, which is 3 to 4 iterations.

  There are actually 9 bits on the wire, not 8, since there is an
  ACK/NACK bit after the actual data transfer. So i changed the delay to
  (9 * 1000) / i2c->bus_clock_khz. That resulted in ocores_wait() mostly
  not looping at all. But for reading an 4K AT24 EEPROM, it increased
  the read time by 10ms, from 424ms to 434ms. So we should probably keep
  with 8.

Signed-off-by: Federico Vaga 
Tested-by: Andrew Lunn 
---
 drivers/i2c/busses/i2c-ocores.c | 182 +++-
 1 file changed, 161 insertions(+), 21 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index fcc2558..5dea7b9 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -13,6 +13,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,6 +27,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#define OCORES_FLAG_POLL BIT(0)
 
 /**
  * @process_lock: protect I2C transfer process.
@@ -35,6 +39,7 @@ struct ocores_i2c {
void __iomem *base;
u32 reg_shift;
u32 reg_io_width;
+   unsigned long flags;
wait_queue_head_t wait;
struct i2c_adapter adap;
struct i2c_msg *msg;
@@ -246,10 +251,116 @@ static void ocores_process_timeout(struct ocores_i2c 
*i2c)
spin_unlock_irqrestore(>process_lock, flags);
 }
 
-static int ocores_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
+/**
+ * Wait until something change in a given register
+ * @i2c: ocores I2C device instance
+ * @reg: register to query
+ * @mask: bitmask to apply on register value
+ * @val: expected result
+ * @timeout: timeout in jiffies
+ *
+ * Timeout is necessary to avoid to stay here forever when the chip
+ * does not answer correctly.
+ *
+ * Return: 0 on success, -ETIMEDOUT on timeout
+ */
+static int ocores_wait(struct ocores_i2c *i2c,
+  int reg, u8 mask, u8 val,
+  const unsigned long timeout)
+{
+   unsigned long j;
+
+   j = jiffies + timeout;
+   while (1) {
+   u8 status = oc_getreg(i2c, reg);
+
+   if ((status & mask) == val)
+   break;
+
+   if (time_after(jiffies, j))
+   return -ETIMEDOUT;
+   }
+   return 0;
+}
+
+/**
+ * Wait until is possible to process some data
+ * @i2c: ocores I2C device instance
+ *
+ * Used when the device is in polling mode (interrupts disabled).
+ *
+ * Return: 0 on success, -ETIMEDOUT on timeout
+ */
+static int ocores_poll_wait(struct ocores_i2c *i2c)
+{
+   u8 mask;
+   int err;
+
+   if (i2c->state == STATE_DONE || i2c->state == STATE_ERROR) {
+   /* transfer is over */
+   mask = OCI2C_STAT_BUSY;
+   } else {
+   /* on going transfer */
+   mask = OCI2C_STAT_TIP;
+   /*
+* We wait for the data to be transferred (8bit),
+* then we start polling on the ACK/NACK bit
+*/
+   udelay((8 * 1000) / i2c->bus_clock_khz);
+   }
+
+   /*
+* once we are here we expect to get the expected result immediately
+* so if after 1ms we timeout then something is broken.
+*/
+   err = ocores_wait(i2c, OCI2C_STATUS, mask, 0, msecs_to_jiffies(1));
+   if (err)
+   dev_warn(i2c->adap.dev.parent,
+"%s: STATUS timeout, bit 0x%x did not clear in 1ms\n",
+__func__, mask);
+   return err;
+}
+
+/**
+ * It handles an IRQ-less transfer
+ * @i2c: ocores I2C device instance
+ *
+ * Even if IRQ are disabled, the I2C OpenCore IP behavior is exactly the same
+ * (only that IRQ are not produced). This means that we can re-use entirely
+ * ocores_isr(), we just add our polling code around it.
+ *
+ * It can run in atomic context
+ */
+static void ocores_process_polling(struct ocores_i2c *i2c)
+{
+   while (1) {
+   irqreturn_t ret;
+   int err;
+
+   err = ocores_poll_wait(i2c);
+   if (err) {
+   i2c->state = STATE_ERROR;
+   break; /* timeout */
+   }
+
+   ret = ocores_isr(-1, i2c);
+   if (ret == IRQ_NONE)
+   break; /* all messages have been transferred */
+   }
+}
+
+static int ocores_xfer_core(struct ocores_i2c *i2c,
+   struct i2c_msg *msgs, int num,
+   bool polling)
 {
-   struct ocor

[PATCH v5 4/5] i2c:ocores: add SPDX tag

[Federico Vaga]

It adds the SPDX tag and it removes the old text about the GPLv2.

Signed-off-by: Federico Vaga 
---
 drivers/i2c/busses/i2c-ocores.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 5dea7b9..78085a8 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * i2c-ocores.c: I2C bus driver for OpenCores I2C controller
  * (https://opencores.org/project/i2c/overview)
@@ -6,10 +7,6 @@
  *
  * Support for the GRLIB port of the controller by
  * Andreas Larsson 
- *
- * This file is licensed under the terms of the GNU General Public License
- * version 2.  This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
  */
 
 #include 
-- 
2.15.0

[PATCH v5 2/5] i2c:ocores: do not handle IRQ if IF is not set

[Federico Vaga]

If the Interrupt Flag (IF) is not set, we should not handle the IRQ:
- the line can be shared with other devices
- it can be a spurious interrupt

To avoid reading twice the status register, the ocores_process() function
expects it to be read by the caller.

Signed-off-by: Federico Vaga 
Acked-by: Peter Korsgaard 
---
 drivers/i2c/busses/i2c-ocores.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index aa85202..fcc2558 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -143,10 +143,9 @@ static inline u8 oc_getreg(struct ocores_i2c *i2c, int reg)
return i2c->getreg(i2c, reg);
 }
 
-static void ocores_process(struct ocores_i2c *i2c)
+static void ocores_process(struct ocores_i2c *i2c, u8 stat)
 {
struct i2c_msg *msg = i2c->msg;
-   u8 stat = oc_getreg(i2c, OCI2C_STATUS);
unsigned long flags;
 
/*
@@ -223,8 +222,12 @@ out:
 static irqreturn_t ocores_isr(int irq, void *dev_id)
 {
struct ocores_i2c *i2c = dev_id;
+   u8 stat = oc_getreg(i2c, OCI2C_STATUS);
+
+   if (!(stat & OCI2C_STAT_IF))
+   return IRQ_NONE;
 
-   ocores_process(i2c);
+   ocores_process(i2c, stat);
 
return IRQ_HANDLED;
 }
-- 
2.15.0

[PATCH v5 5/5] i2c:ocores: checkpatch fixes

[Federico Vaga]

Miscellaneous style fixes from checkpatch

Signed-off-by: Federico Vaga 
---
 drivers/i2c/busses/i2c-ocores.c | 30 +++---
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 78085a8..54b2156 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -179,8 +179,9 @@ static void ocores_process(struct ocores_i2c *i2c, u8 stat)
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
goto out;
}
-   } else
+   } else {
msg->buf[i2c->pos++] = oc_getreg(i2c, OCI2C_DATA);
+   }
 
/* end of msg? */
if (i2c->pos == msg->len) {
@@ -197,11 +198,11 @@ static void ocores_process(struct ocores_i2c *i2c, u8 
stat)
i2c->state = STATE_START;
 
oc_setreg(i2c, OCI2C_DATA, addr);
-   oc_setreg(i2c, OCI2C_CMD,  OCI2C_CMD_START);
+   oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_START);
goto out;
-   } else
-   i2c->state = (msg->flags & I2C_M_RD)
-   ? STATE_READ : STATE_WRITE;
+   }
+   i2c->state = (msg->flags & I2C_M_RD)
+   ? STATE_READ : STATE_WRITE;
} else {
i2c->state = STATE_DONE;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
@@ -461,13 +462,16 @@ static const struct of_device_id ocores_i2c_match[] = {
 MODULE_DEVICE_TABLE(of, ocores_i2c_match);
 
 #ifdef CONFIG_OF
-/* Read and write functions for the GRLIB port of the controller. Registers are
+/*
+ * Read and write functions for the GRLIB port of the controller. Registers are
  * 32-bit big endian and the PRELOW and PREHIGH registers are merged into one
- * register. The subsequent registers has their offset decreased accordingly. 
*/
+ * register. The subsequent registers have their offsets decreased accordingly.
+ */
 static u8 oc_getreg_grlib(struct ocores_i2c *i2c, int reg)
 {
u32 rd;
int rreg = reg;
+
if (reg != OCI2C_PRELOW)
rreg--;
rd = ioread32be(i2c->base + (rreg << i2c->reg_shift));
@@ -481,6 +485,7 @@ static void oc_setreg_grlib(struct ocores_i2c *i2c, int 
reg, u8 value)
 {
u32 curr, wr;
int rreg = reg;
+
if (reg != OCI2C_PRELOW)
rreg--;
if (reg == OCI2C_PRELOW || reg == OCI2C_PREHIGH) {
@@ -569,7 +574,7 @@ static int ocores_i2c_of_probe(struct platform_device *pdev,
return 0;
 }
 #else
-#define ocores_i2c_of_probe(pdev,i2c) -ENODEV
+#define ocores_i2c_of_probe(pdev, i2c) -ENODEV
 #endif
 
 static int ocores_i2c_probe(struct platform_device *pdev)
@@ -686,10 +691,11 @@ err_clk:
 static int ocores_i2c_remove(struct platform_device *pdev)
 {
struct ocores_i2c *i2c = platform_get_drvdata(pdev);
+   u8 ctrl = oc_getreg(i2c, OCI2C_CONTROL);
 
/* disable i2c logic */
-   oc_setreg(i2c, OCI2C_CONTROL, oc_getreg(i2c, OCI2C_CONTROL)
- & ~(OCI2C_CTRL_EN|OCI2C_CTRL_IEN));
+   ctrl &= ~(OCI2C_CTRL_EN | OCI2C_CTRL_IEN);
+   oc_setreg(i2c, OCI2C_CONTROL, ctrl);
 
/* remove adapter & data */
i2c_del_adapter(>adap);
@@ -707,7 +713,9 @@ static int ocores_i2c_suspend(struct device *dev)
u8 ctrl = oc_getreg(i2c, OCI2C_CONTROL);
 
/* make sure the device is disabled */
-   oc_setreg(i2c, OCI2C_CONTROL, ctrl & ~(OCI2C_CTRL_EN|OCI2C_CTRL_IEN));
+   ctrl = oc_getreg(i2c, OCI2C_CONTROL);
+   ctrl &= ~(OCI2C_CTRL_EN | OCI2C_CTRL_IEN);
+   oc_setreg(i2c, OCI2C_CONTROL, ctrl);
 
if (!IS_ERR(i2c->clk))
clk_disable_unprepare(i2c->clk);
-- 
2.15.0

Re: [PATCH v4 1/5] i2c:ocores: stop transfer on timeout

[Federico Vaga]

On Monday, February 11, 2019 3:01:38 PM CET Andrew Lunn wrote:
> > Applied to for-next, thanks!
> 
> Hi Wolfram
> 
> Could you drop these patches and wait for a new version?  I don't
> think you have pushed it out yet? So it won't be a visible rebase.

I will wait to send v5: full patch set, or just PATCH 3 and 5 ?

> 
> Thanks
>   Andrew

Re: [PATCH v4 3/5] i2c:ocores: add polling interface

[Federico Vaga]

On Monday, February 11, 2019 11:25:26 AM CET Wolfram Sang wrote:
> On Mon, Feb 11, 2019 at 09:31:20AM +0100, Federico Vaga wrote:
> > This driver assumes that an interrupt line is always available for
> > the I2C master. This is not always the case and this patch adds support
> > for a polling version.
> > 
> > Report from Andrew Lunn:
> >   I did some timing tests for this. On my box, we request a udelay of
> >   80uS. The kernel actually delays for about 79uS. We then spin in
> >   ocores_wait() for an additional 10-11uS, which is 3 to 4 iterations.
> >   
> >   There are actually 9 bits on the wire, not 8, since there is an
> >   ACK/NACK bit after the actual data transfer. So i changed the delay to
> >   (9 * 1000) / i2c->bus_clock_khz. That resulted in ocores_wait() mostly
> >   not looping at all. But for reading an 4K AT24 EEPROM, it increased
> >   the read time by 10ms, from 424ms to 434ms. So we should probably keep
> >   with 8.
> > 
> > Signed-off-by: Federico Vaga 
> > Tested-by: Andrew Lunn 
> 
> Fixed these checkpatch warnings:
> 
> WARNING: 'transfered' may be misspelled - perhaps 'transferred'?
> #111: FILE: drivers/i2c/busses/i2c-ocores.c:306:
> +  * We wait for the data to be transfered (8bit),
> 
> CHECK: Please don't use multiple blank lines
> #129: FILE: drivers/i2c/busses/i2c-ocores.c:324:
> +
> +
> 
> WARNING: 'transfered' may be misspelled - perhaps 'transferred'?
> #154: FILE: drivers/i2c/busses/i2c-ocores.c:349:
> + break; /* all messages have been transfered */
> 
> and applied to for-next, thanks!

I will resend this patch as v5 to add the fix suggested by Peter Rosin

Re: [PATCH v4 3/5] i2c:ocores: add polling interface

[Federico Vaga]

On Monday, February 11, 2019 2:35:15 PM CET Peter Rosin wrote:
> >>> @@ -294,7 +427,7 @@ static int ocores_init(struct device *dev, struct
> >>> ocores_i2c *i2c)
> >>
> >>
> >>
> >>>  
> >>>  
> >>>  
> >>>   /* Init the device */
> >>>   oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_IACK);
> >>>
> >>>
> >>>
> >>> - oc_setreg(i2c, OCI2C_CONTROL, ctrl | OCI2C_CTRL_IEN | OCI2C_CTRL_EN);
> >>> + oc_setreg(i2c, OCI2C_CONTROL, ctrl | OCI2C_CTRL_EN);
> >>
> >>
> >>
> >>
> >> You fix this up in patch 5 (in what is perhaps carelessly marketed as
> >> fixes for minor checkpatch issues), but for this patch you are actually
> >> no longer making sure that you clear the OCI2C_CTRL_IEN bit as the code
> >> used to before this patch. I think you intended to preserve that
> >> behavior, no?
> > 
> > 
> > I think you got confused by the two patches because those lines look very
> > 
> > similar.
> > 
> > In PATCH 5 what you see is the "style fix" to clear EN and IEN before
> > clock 
 configuration
> > 
> > in PATCH 3 (this one) what you see is when later (same function, after
> > clock 
 configuration) the device is re-enabled (EN), but without
> > enabling the interrupt because on polling configuration we do not want to
> > see interrupt flowing.
> > 
> > So, the behavior is preserved for what concern clearing the IEN bit before
> > 
 clock configuration.
> > 
> > am I wrong?
> 
> 
> No, I don't think I'm confused and I think you are wrong. Current code does
> this:
> 
>   u8 ctrl = oc_getreg(i2c, OCI2C_CONTROL);
> 
>   /* make sure the device is disabled */
>   oc_setreg(i2c, OCI2C_CONTROL, ctrl & ~(OCI2C_CTRL_IEN|OCI2C_CTRL_EN));
>   ...
>   oc_setreg(i2c, OCI2C_CONTROL, ctrl | OCI2C_CTRL_IEN | OCI2C_CTRL_EN));
> 
> Here, the final oc_setreg always sets OCI2C_CTRL_IEN.
> 
> Patch 3 changes it to:
> 
>   u8 ctrl = oc_getreg(i2c, OCI2C_CONTROL);
> 
>   /* make sure the device is disabled */
>   oc_setreg(i2c, OCI2C_CONTROL, ctrl & ~(OCI2C_CTRL_IEN|OCI2C_CTRL_EN));
>   ...
>   oc_setreg(i2c, OCI2C_CONTROL, ctrl | OCI2C_CTRL_EN));
> 
> Here, the final oc_setreg restores OCI2C_CTRL_IEN to whatever it was
> at function entry.
> 
> 
> And patch 5 changes it again to:
> 
>   u8 ctrl = oc_getreg(i2c, OCI2C_CONTROL);
> 
>   /* make sure the device is disabled */
>   ctrl &= ~(OCI2C_CTRL_IEN | OCI2C_CTRL_EN);
>   oc_setreg(i2c, OCI2C_CONTROL, ctrl);
>   ...
>   oc_setreg(i2c, OCI2C_CONTROL, ctrl | OCI2C_CTRL_EN));
> 
> Here, the final oc_setreg keeps OCI2C_CTRL_IEN cleared. I think you wanted
> this deterministic behavior for patch 3 as well.

Now I see what you mean and I agree. I will move the fix from PATCH 5 to PATCH 
3, so that bit IEN is clearly cleared.


thanks

> 
> Cheers,
> Peter

Re: [PATCH v4 3/5] i2c:ocores: add polling interface

[Federico Vaga]

On Monday, February 11, 2019 11:43:45 AM CET Peter Rosin wrote:
> On 2019-02-11 09:31, Federico Vaga wrote:
> 
> > This driver assumes that an interrupt line is always available for
> > the I2C master. This is not always the case and this patch adds support
> > for a polling version.
> > 
> > Report from Andrew Lunn:
> > 
> > 
> >   I did some timing tests for this. On my box, we request a udelay of
> >   80uS. The kernel actually delays for about 79uS. We then spin in
> >   ocores_wait() for an additional 10-11uS, which is 3 to 4 iterations.
> > 
> > 
> > 
> >   There are actually 9 bits on the wire, not 8, since there is an
> >   ACK/NACK bit after the actual data transfer. So i changed the delay to
> >   (9 * 1000) / i2c->bus_clock_khz. That resulted in ocores_wait() mostly
> >   not looping at all. But for reading an 4K AT24 EEPROM, it increased
> >   the read time by 10ms, from 424ms to 434ms. So we should probably keep
> >   with 8.
> > 
> > 
> > Signed-off-by: Federico Vaga 
> > Tested-by: Andrew Lunn 
> > 
> > ---
> > 
> >  drivers/i2c/busses/i2c-ocores.c | 180
> >  +++-
 1 file changed, 160
> >  insertions(+), 20 deletions(-)
> > 
> > 
> > diff --git a/drivers/i2c/busses/i2c-ocores.c
> > b/drivers/i2c/busses/i2c-ocores.c
 index fcc2558..d42a324 100644
> > --- a/drivers/i2c/busses/i2c-ocores.c
> > +++ b/drivers/i2c/busses/i2c-ocores.c
> > @@ -13,6 +13,7 @@
> > 
> >   */
> >  
> >  
> >  #include 
> > 
> > +#include 
> > 
> >  #include 
> >  #include 
> >  #include 
> > 
> > @@ -26,6 +27,9 @@
> > 
> >  #include 
> >  #include 
> >  #include 
> > 
> > +#include 
> > +
> > +#define OCORES_FLAG_POLL BIT(0)
> > 
> >  
> >  /**
> >  
> >   * @process_lock: protect I2C transfer process.
> > 
> > @@ -35,6 +39,7 @@ struct ocores_i2c {
> > 
> > void __iomem *base;
> > u32 reg_shift;
> > u32 reg_io_width;
> > 
> > +   unsigned long flags;
> > 
> > wait_queue_head_t wait;
> > struct i2c_adapter adap;
> > struct i2c_msg *msg;
> > 
> > @@ -246,10 +251,117 @@ static void ocores_process_timeout(struct
> > ocores_i2c *i2c)
> 
> > spin_unlock_irqrestore(>process_lock, flags);
> >  
> >  }
> >  
> > 
> > -static int ocores_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
> > int num)
 +/**
> > + * Wait until something change in a given register
> > + * @i2c: ocores I2C device instance
> > + * @reg: register to query
> > + * @mask: bitmask to apply on register value
> > + * @val: expected result
> > + * @timeout: timeout in jiffies
> > + *
> > + * Timeout is necessary to avoid to stay here forever when the chip
> > + * does not answer correctly.
> > + *
> > + * Return: 0 on success, -ETIMEDOUT on timeout
> > + */
> > +static int ocores_wait(struct ocores_i2c *i2c,
> > +  int reg, u8 mask, u8 val,
> > +  const unsigned long timeout)
> > +{
> > +   unsigned long j;
> > +
> > +   j = jiffies + timeout;
> > +   while (1) {
> > +   u8 status = oc_getreg(i2c, reg);
> > +
> > +   if ((status & mask) == val)
> > +   break;
> > +
> > +   if (time_after(jiffies, j))
> > +   return -ETIMEDOUT;
> > +   }
> > +   return 0;
> > +}
> > +
> > +/**
> > + * Wait until is possible to process some data
> > + * @i2c: ocores I2C device instance
> > + *
> > + * Used when the device is in polling mode (interrupts disabled).
> > + *
> > + * Return: 0 on success, -ETIMEDOUT on timeout
> > + */
> > +static int ocores_poll_wait(struct ocores_i2c *i2c)
> > +{
> > +   u8 mask;
> > +   int err;
> > +
> > +   if (i2c->state == STATE_DONE || i2c->state == STATE_ERROR) {
> > +   /* transfer is over */
> > +   mask = OCI2C_STAT_BUSY;
> > +   } else {
> > +   /* on going transfer */
> > +   mask = OCI2C_STAT_TIP;
> > +   /*
> > +* We wait for the data to be transfered (8bit),
> > +* then we start polling on the ACK/NACK bit
> > +*/
> > +   udelay((8 * 1000) / i2c->bus_clock_khz);
> > +   }
> > +
> > +   /*
> > +* once we are here we exp

Re: [PATCH v4 1/5] i2c:ocores: stop transfer on timeout

[Federico Vaga]

On Monday, February 11, 2019 11:44:46 AM CET Peter Rosin wrote:
> On 2019-02-11 09:31, Federico Vaga wrote:
> 
> > Detecting a timeout is ok, but we also need to assert a STOP command on
> > the bus in order to prevent it from generating interrupts when there are
> > no on going transfers.
> > 
> > Example: very long transmission.
> > 
> > 1. ocores_xfer: START a transfer
> > 2. ocores_isr : handle byte by byte the transfer
> > 3. ocores_xfer: goes in timeout [[bugfix here]]
> > 4. ocores_xfer: return to I2C subsystem and to the I2C driver
> > 5. I2C driver : it may clean up the i2c_msg memory
> > 6. ocores_isr : receives another interrupt (pending bytes to be
> > 
> > transferred) but the i2c_msg memory is invalid now
> > 
> > 
> > So, since the transfer was too long, we have to detect the timeout and
> > STOP the transfer.
> > 
> > Another point is that we have a critical region here. When handling the
> > timeout condition we may have a running IRQ handler. For this reason I
> > introduce a spinlock.
> > 
> > In order to make easier to understan locking I have:
> > - added a new function to handle timeout
> > - modified the current ocores_process() function in order to be protected
> > 
> >   by the new spinlock
> > 
> > Like this it is obvious at first sight that this locking serializes
> > the execution of ocores_process() and ocores_process_timeout()
> > 
> 
> 
> *snip*
> 
> 
> > @@ -184,14 +197,14 @@ static void ocores_process(struct ocores_i2c *i2c)
> > 
> >  
> >  
> > oc_setreg(i2c, OCI2C_DATA, addr);
> > oc_setreg(i2c, OCI2C_CMD,  OCI2C_CMD_START);
> 
> 
> Didn't checkpatch complain about the double space? Fixing it fits in
> patch 5...

Apparently not, I will add the fix the checkpatch PATCH

> Cheers,
> Peter

Re: [PATCH] doc:dmaengine: clarify DMA desc. pointer after submission

[Federico Vaga]

On Monday, February 11, 2019 12:54:11 PM CET Vinod Koul wrote:
> On 08-02-19, 16:30, Federico Vaga wrote:
> > It clarifies that the DMA description pointer returned by
> > `dmaengine_prep_*` function should not be used after submission.
> > 
> > Signed-off-by: Federico Vaga 
> > ---
> > 
> >  Documentation/driver-api/dmaengine/client.rst | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/Documentation/driver-api/dmaengine/client.rst
> > b/Documentation/driver-api/dmaengine/client.rst index
> > fbbb2831f29f..d728e50105eb 100644
> > --- a/Documentation/driver-api/dmaengine/client.rst
> > +++ b/Documentation/driver-api/dmaengine/client.rst
> > 
> > @@ -168,6 +168,13 @@ The details of these operations are:
> > dmaengine_submit() will not start the DMA operation, it merely adds
> > it to the pending queue. For this, see step 5,
> > dma_async_issue_pending.
> > 
> > +   .. note::
> > +
> > +  After calling ``dmaengine_submit()`` the submitted transfer
> > descriptor +  (``struct dma_async_tx_descriptor``) belongs to the DMA
> > engine. +  Consequentially, the client must consider invalid the
> > pointer to that
> Consequently

I'm not a native speaker but consequentially and consequently should be 
synonymous. As fa as I understood. but I do not mind to change it if you think 
is better.

> > +  descriptor.
> > +
> 
> Applied after fixing the typo and added tag as Documentation: dmaengine...

I used doc to make the string shorter

> 
> >  5. Issue pending DMA requests and wait for callback notification
> >  
> > The transactions in the pending queue can be activated by calling the

[PATCH v4 0/5] i2c:ocores: improvements

[Federico Vaga]

This patch set provides improvements to the i2c-ocore driver.

[V3 -> V4]
- add reviews-by/tested-by
- add comment to justify the formula in
udelay((8 * 1000) / i2c->bus_clock_khz);

[V2 -> V3]
- fix particular error condition on platform_get_irq(). Copied from
  https://patchwork.ozlabs.org/patch/1038409/

[V1 -> V2]
- replaced usleep_range() with udelay() so that the polling version can be
  used in atomic context.
- added dedicated patch for minor style issues
- fixed delay computation
- use spin_lock_irqsave(), instead of spin_trylock_irqsave(). IACK is always
  necessary and a trylock would generate an extra interrupt for nothing
- make the driver ready for an eventual master_xfer_irqless()

[PATCH v4 5/5] i2c:ocores: checkpatch fixes

[Federico Vaga]

Miscellaneous style fixes from checkpatch

Signed-off-by: Federico Vaga 
Reviewed-by: Andrew Lunn 

---
 drivers/i2c/busses/i2c-ocores.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 5b80190..ba35d2a 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -182,8 +182,9 @@ static void ocores_process(struct ocores_i2c *i2c, u8 stat)
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
goto out;
}
-   } else
+   } else {
msg->buf[i2c->pos++] = oc_getreg(i2c, OCI2C_DATA);
+   }
 
/* end of msg? */
if (i2c->pos == msg->len) {
@@ -202,9 +203,9 @@ static void ocores_process(struct ocores_i2c *i2c, u8 stat)
oc_setreg(i2c, OCI2C_DATA, addr);
oc_setreg(i2c, OCI2C_CMD,  OCI2C_CMD_START);
goto out;
-   } else
-   i2c->state = (msg->flags & I2C_M_RD)
-   ? STATE_READ : STATE_WRITE;
+   }
+   i2c->state = (msg->flags & I2C_M_RD)
+   ? STATE_READ : STATE_WRITE;
} else {
i2c->state = STATE_DONE;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
@@ -405,7 +406,8 @@ static int ocores_init(struct device *dev, struct 
ocores_i2c *i2c)
u8 ctrl = oc_getreg(i2c, OCI2C_CONTROL);
 
/* make sure the device is disabled */
-   oc_setreg(i2c, OCI2C_CONTROL, ctrl & ~(OCI2C_CTRL_EN|OCI2C_CTRL_IEN));
+   ctrl &= ~(OCI2C_CTRL_EN | OCI2C_CTRL_IEN);
+   oc_setreg(i2c, OCI2C_CONTROL, ctrl);
 
prescale = (i2c->ip_clock_khz / (5 * i2c->bus_clock_khz)) - 1;
prescale = clamp(prescale, 0, 0x);
@@ -462,11 +464,13 @@ MODULE_DEVICE_TABLE(of, ocores_i2c_match);
 #ifdef CONFIG_OF
 /* Read and write functions for the GRLIB port of the controller. Registers are
  * 32-bit big endian and the PRELOW and PREHIGH registers are merged into one
- * register. The subsequent registers has their offset decreased accordingly. 
*/
+ * register. The subsequent registers has their offset decreased accordingly.
+ */
 static u8 oc_getreg_grlib(struct ocores_i2c *i2c, int reg)
 {
u32 rd;
int rreg = reg;
+
if (reg != OCI2C_PRELOW)
rreg--;
rd = ioread32be(i2c->base + (rreg << i2c->reg_shift));
@@ -480,6 +484,7 @@ static void oc_setreg_grlib(struct ocores_i2c *i2c, int 
reg, u8 value)
 {
u32 curr, wr;
int rreg = reg;
+
if (reg != OCI2C_PRELOW)
rreg--;
if (reg == OCI2C_PRELOW || reg == OCI2C_PREHIGH) {
@@ -568,7 +573,7 @@ static int ocores_i2c_of_probe(struct platform_device *pdev,
return 0;
 }
 #else
-#define ocores_i2c_of_probe(pdev,i2c) -ENODEV
+#define ocores_i2c_of_probe(pdev, i2c) -ENODEV
 #endif
 
 static int ocores_i2c_probe(struct platform_device *pdev)
-- 
2.15.0

[PATCH v4 1/5] i2c:ocores: stop transfer on timeout

[Federico Vaga]

Detecting a timeout is ok, but we also need to assert a STOP command on
the bus in order to prevent it from generating interrupts when there are
no on going transfers.

Example: very long transmission.

1. ocores_xfer: START a transfer
2. ocores_isr : handle byte by byte the transfer
3. ocores_xfer: goes in timeout [[bugfix here]]
4. ocores_xfer: return to I2C subsystem and to the I2C driver
5. I2C driver : it may clean up the i2c_msg memory
6. ocores_isr : receives another interrupt (pending bytes to be
transferred) but the i2c_msg memory is invalid now

So, since the transfer was too long, we have to detect the timeout and
STOP the transfer.

Another point is that we have a critical region here. When handling the
timeout condition we may have a running IRQ handler. For this reason I
introduce a spinlock.

In order to make easier to understan locking I have:
- added a new function to handle timeout
- modified the current ocores_process() function in order to be protected
  by the new spinlock
Like this it is obvious at first sight that this locking serializes
the execution of ocores_process() and ocores_process_timeout()

Signed-off-by: Federico Vaga 
Reviewed-by: Andrew Lunn 

---
 drivers/i2c/busses/i2c-ocores.c | 54 ++---
 1 file changed, 45 insertions(+), 9 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 87f9caa..aa85202 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -25,7 +25,12 @@
 #include 
 #include 
 #include 
+#include 
 
+/**
+ * @process_lock: protect I2C transfer process.
+ * ocores_process() and ocores_process_timeout() can't run in parallel.
+ */
 struct ocores_i2c {
void __iomem *base;
u32 reg_shift;
@@ -36,6 +41,7 @@ struct ocores_i2c {
int pos;
int nmsgs;
int state; /* see STATE_ */
+   spinlock_t process_lock;
struct clk *clk;
int ip_clock_khz;
int bus_clock_khz;
@@ -141,19 +147,26 @@ static void ocores_process(struct ocores_i2c *i2c)
 {
struct i2c_msg *msg = i2c->msg;
u8 stat = oc_getreg(i2c, OCI2C_STATUS);
+   unsigned long flags;
+
+   /*
+* If we spin here is because we are in timeout, so we are going
+* to be in STATE_ERROR. See ocores_process_timeout()
+*/
+   spin_lock_irqsave(>process_lock, flags);
 
if ((i2c->state == STATE_DONE) || (i2c->state == STATE_ERROR)) {
/* stop has been sent */
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_IACK);
wake_up(>wait);
-   return;
+   goto out;
}
 
/* error? */
if (stat & OCI2C_STAT_ARBLOST) {
i2c->state = STATE_ERROR;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
-   return;
+   goto out;
}
 
if ((i2c->state == STATE_START) || (i2c->state == STATE_WRITE)) {
@@ -163,7 +176,7 @@ static void ocores_process(struct ocores_i2c *i2c)
if (stat & OCI2C_STAT_NACK) {
i2c->state = STATE_ERROR;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
-   return;
+   goto out;
}
} else
msg->buf[i2c->pos++] = oc_getreg(i2c, OCI2C_DATA);
@@ -184,14 +197,14 @@ static void ocores_process(struct ocores_i2c *i2c)
 
oc_setreg(i2c, OCI2C_DATA, addr);
oc_setreg(i2c, OCI2C_CMD,  OCI2C_CMD_START);
-   return;
+   goto out;
} else
i2c->state = (msg->flags & I2C_M_RD)
? STATE_READ : STATE_WRITE;
} else {
i2c->state = STATE_DONE;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
-   return;
+   goto out;
}
}
 
@@ -202,6 +215,9 @@ static void ocores_process(struct ocores_i2c *i2c)
oc_setreg(i2c, OCI2C_DATA, msg->buf[i2c->pos++]);
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_WRITE);
}
+
+out:
+   spin_unlock_irqrestore(>process_lock, flags);
 }
 
 static irqreturn_t ocores_isr(int irq, void *dev_id)
@@ -213,9 +229,24 @@ static irqreturn_t ocores_isr(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+/**
+ * Process timeout event
+ * @i2c: ocores I2C device instance
+ */
+static void ocores_process_timeout(struct ocores_i2c *i2c)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>process_lock, flags);
+   i2c->state = STATE_ERROR;
+   oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
+   spin_unlock_irqrestore(>process_lock, flags);
+}
+
 static int ocores_xfer(st

[PATCH v4 3/5] i2c:ocores: add polling interface

[Federico Vaga]

This driver assumes that an interrupt line is always available for
the I2C master. This is not always the case and this patch adds support
for a polling version.

Report from Andrew Lunn:

  I did some timing tests for this. On my box, we request a udelay of
  80uS. The kernel actually delays for about 79uS. We then spin in
  ocores_wait() for an additional 10-11uS, which is 3 to 4 iterations.

  There are actually 9 bits on the wire, not 8, since there is an
  ACK/NACK bit after the actual data transfer. So i changed the delay to
  (9 * 1000) / i2c->bus_clock_khz. That resulted in ocores_wait() mostly
  not looping at all. But for reading an 4K AT24 EEPROM, it increased
  the read time by 10ms, from 424ms to 434ms. So we should probably keep
  with 8.

Signed-off-by: Federico Vaga 
Tested-by: Andrew Lunn 

---
 drivers/i2c/busses/i2c-ocores.c | 180 +++-
 1 file changed, 160 insertions(+), 20 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index fcc2558..d42a324 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -13,6 +13,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,6 +27,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#define OCORES_FLAG_POLL BIT(0)
 
 /**
  * @process_lock: protect I2C transfer process.
@@ -35,6 +39,7 @@ struct ocores_i2c {
void __iomem *base;
u32 reg_shift;
u32 reg_io_width;
+   unsigned long flags;
wait_queue_head_t wait;
struct i2c_adapter adap;
struct i2c_msg *msg;
@@ -246,10 +251,117 @@ static void ocores_process_timeout(struct ocores_i2c 
*i2c)
spin_unlock_irqrestore(>process_lock, flags);
 }
 
-static int ocores_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
+/**
+ * Wait until something change in a given register
+ * @i2c: ocores I2C device instance
+ * @reg: register to query
+ * @mask: bitmask to apply on register value
+ * @val: expected result
+ * @timeout: timeout in jiffies
+ *
+ * Timeout is necessary to avoid to stay here forever when the chip
+ * does not answer correctly.
+ *
+ * Return: 0 on success, -ETIMEDOUT on timeout
+ */
+static int ocores_wait(struct ocores_i2c *i2c,
+  int reg, u8 mask, u8 val,
+  const unsigned long timeout)
+{
+   unsigned long j;
+
+   j = jiffies + timeout;
+   while (1) {
+   u8 status = oc_getreg(i2c, reg);
+
+   if ((status & mask) == val)
+   break;
+
+   if (time_after(jiffies, j))
+   return -ETIMEDOUT;
+   }
+   return 0;
+}
+
+/**
+ * Wait until is possible to process some data
+ * @i2c: ocores I2C device instance
+ *
+ * Used when the device is in polling mode (interrupts disabled).
+ *
+ * Return: 0 on success, -ETIMEDOUT on timeout
+ */
+static int ocores_poll_wait(struct ocores_i2c *i2c)
+{
+   u8 mask;
+   int err;
+
+   if (i2c->state == STATE_DONE || i2c->state == STATE_ERROR) {
+   /* transfer is over */
+   mask = OCI2C_STAT_BUSY;
+   } else {
+   /* on going transfer */
+   mask = OCI2C_STAT_TIP;
+   /*
+* We wait for the data to be transfered (8bit),
+* then we start polling on the ACK/NACK bit
+*/
+   udelay((8 * 1000) / i2c->bus_clock_khz);
+   }
+
+   /*
+* once we are here we expect to get the expected result immediately
+* so if after 1ms we timeout then something is broken.
+*/
+   err = ocores_wait(i2c, OCI2C_STATUS, mask, 0, msecs_to_jiffies(1));
+   if (err)
+   dev_warn(i2c->adap.dev.parent,
+"%s: STATUS timeout, bit 0x%x did not clear in 1ms\n",
+__func__, mask);
+   return err;
+}
+
+
+/**
+ * It handles an IRQ-less transfer
+ * @i2c: ocores I2C device instance
+ *
+ * Even if IRQ are disabled, the I2C OpenCore IP behavior is exactly the same
+ * (only that IRQ are not produced). This means that we can re-use entirely
+ * ocores_isr(), we just add our polling code around it.
+ *
+ * It can run in atomic context
+ */
+static void ocores_process_polling(struct ocores_i2c *i2c)
+{
+   while (1) {
+   irqreturn_t ret;
+   int err;
+
+   err = ocores_poll_wait(i2c);
+   if (err) {
+   i2c->state = STATE_ERROR;
+   break; /* timeout */
+   }
+
+   ret = ocores_isr(-1, i2c);
+   if (ret == IRQ_NONE)
+   break; /* all messages have been transfered */
+   }
+}
+
+static int ocores_xfer_core(struct ocores_i2c *i2c,
+   struct i2c_msg *msgs, int num,
+   bool polling)
 {
-   struct ocor

[PATCH v4 4/5] i2c:ocores: add SPDX tag

[Federico Vaga]

It adds the SPDX tag and it removes the old text about the GPLv2.

Signed-off-by: Federico Vaga 
Reviewed-by: Andrew Lunn 

---
 drivers/i2c/busses/i2c-ocores.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index bbe3e96..e87fce0 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * i2c-ocores.c: I2C bus driver for OpenCores I2C controller
  * (https://opencores.org/project/i2c/overview)
@@ -6,10 +7,6 @@
  *
  * Support for the GRLIB port of the controller by
  * Andreas Larsson 
- *
- * This file is licensed under the terms of the GNU General Public License
- * version 2.  This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
  */
 
 #include 
-- 
2.15.0

[PATCH v4 2/5] i2c:ocores: do not handle IRQ if IF is not set

[Federico Vaga]

If the Interrupt Flag (IF) is not set, we should not handle the IRQ:
- the line can be shared with other devices
- it can be a spurious interrupt

To avoid reading twice the status register, the ocores_process() function
expects it to be read by the caller.

Signed-off-by: Federico Vaga 
Acked-by: Peter Korsgaard 
Reviewed-by: Andrew Lunn 

---
 drivers/i2c/busses/i2c-ocores.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index aa85202..fcc2558 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -143,10 +143,9 @@ static inline u8 oc_getreg(struct ocores_i2c *i2c, int reg)
return i2c->getreg(i2c, reg);
 }
 
-static void ocores_process(struct ocores_i2c *i2c)
+static void ocores_process(struct ocores_i2c *i2c, u8 stat)
 {
struct i2c_msg *msg = i2c->msg;
-   u8 stat = oc_getreg(i2c, OCI2C_STATUS);
unsigned long flags;
 
/*
@@ -223,8 +222,12 @@ out:
 static irqreturn_t ocores_isr(int irq, void *dev_id)
 {
struct ocores_i2c *i2c = dev_id;
+   u8 stat = oc_getreg(i2c, OCI2C_STATUS);
+
+   if (!(stat & OCI2C_STAT_IF))
+   return IRQ_NONE;
 
-   ocores_process(i2c);
+   ocores_process(i2c, stat);
 
return IRQ_HANDLED;
 }
-- 
2.15.0

Re: [PATCH v3 3/5] i2c:ocores: add polling interface

[Federico Vaga]

On Saturday, February 9, 2019 10:33:53 PM CET Andrew Lunn wrote:
> > +static int ocores_poll_wait(struct ocores_i2c *i2c)
> > +{
> > +   u8 mask;
> > +   int err;
> > +
> > +   if (i2c->state == STATE_DONE || i2c->state == STATE_ERROR) {
> > +   /* transfer is over */
> > +   mask = OCI2C_STAT_BUSY;
> > +   } else {
> > +   /* on going transfer */
> > +   mask = OCI2C_STAT_TIP;
> > +   udelay((8 * 1000) / i2c->bus_clock_khz);
> > +   }
> > +
> > +   /*
> > +* once we are here we expect to get the expected result immediately
> > +* so if after 1ms we timeout then something is broken.
> > +*/
> > +   err = ocores_wait(i2c, OCI2C_STATUS, mask, 0, msecs_to_jiffies(1));
> 
> Hi Federico
> 
> I did some timing tests for this. On my box, we request a udelay of
> 80uS. The kernel actually delays for about 79uS. We then spin in
> ocores_wait() for an additional 10-11uS, which is 3 to 4 iterations.
> 
> There are actually 9 bits on the wire, not 8, since there is an
> ACK/NACK bit after the actual data transfer. So i changed the delay to
> (9 * 1000) / i2c->bus_clock_khz. That resulted in ocores_wait() mostly
> not looping at all. But for reading an 4K AT24 EEPROM, it increased
> the read time by 10ms, from 424ms to 434ms. So we should probably keep
> with 8.
> 
> Tested-by: Andrew Lunn 

I had a similar experience. I will add a comment in the code to explain that 8 
is not a mistake but a conscious decision. Then I will add what you wrote here
in the patch changelog

> 
> Andrew

[PATCH v3 3/5] i2c:ocores: add polling interface

[Federico Vaga]

This driver assumes that an interrupt line is always available for
the I2C master. This is not always the case and this patch adds support
for a polling version.

Signed-off-by: Federico Vaga 
---
 drivers/i2c/busses/i2c-ocores.c | 176 +++-
 1 file changed, 156 insertions(+), 20 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index fcc2558..bbe3e96 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -13,6 +13,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,6 +27,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#define OCORES_FLAG_POLL BIT(0)
 
 /**
  * @process_lock: protect I2C transfer process.
@@ -35,6 +39,7 @@ struct ocores_i2c {
void __iomem *base;
u32 reg_shift;
u32 reg_io_width;
+   unsigned long flags;
wait_queue_head_t wait;
struct i2c_adapter adap;
struct i2c_msg *msg;
@@ -246,10 +251,113 @@ static void ocores_process_timeout(struct ocores_i2c 
*i2c)
spin_unlock_irqrestore(>process_lock, flags);
 }
 
-static int ocores_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
+/**
+ * Wait until something change in a given register
+ * @i2c: ocores I2C device instance
+ * @reg: register to query
+ * @mask: bitmask to apply on register value
+ * @val: expected result
+ * @timeout: timeout in jiffies
+ *
+ * Timeout is necessary to avoid to stay here forever when the chip
+ * does not answer correctly.
+ *
+ * Return: 0 on success, -ETIMEDOUT on timeout
+ */
+static int ocores_wait(struct ocores_i2c *i2c,
+  int reg, u8 mask, u8 val,
+  const unsigned long timeout)
+{
+   unsigned long j;
+
+   j = jiffies + timeout;
+   while (1) {
+   u8 status = oc_getreg(i2c, reg);
+
+   if ((status & mask) == val)
+   break;
+
+   if (time_after(jiffies, j))
+   return -ETIMEDOUT;
+   }
+   return 0;
+}
+
+/**
+ * Wait until is possible to process some data
+ * @i2c: ocores I2C device instance
+ *
+ * Used when the device is in polling mode (interrupts disabled).
+ *
+ * Return: 0 on success, -ETIMEDOUT on timeout
+ */
+static int ocores_poll_wait(struct ocores_i2c *i2c)
+{
+   u8 mask;
+   int err;
+
+   if (i2c->state == STATE_DONE || i2c->state == STATE_ERROR) {
+   /* transfer is over */
+   mask = OCI2C_STAT_BUSY;
+   } else {
+   /* on going transfer */
+   mask = OCI2C_STAT_TIP;
+   udelay((8 * 1000) / i2c->bus_clock_khz);
+   }
+
+   /*
+* once we are here we expect to get the expected result immediately
+* so if after 1ms we timeout then something is broken.
+*/
+   err = ocores_wait(i2c, OCI2C_STATUS, mask, 0, msecs_to_jiffies(1));
+   if (err)
+   dev_warn(i2c->adap.dev.parent,
+"%s: STATUS timeout, bit 0x%x did not clear in 1ms\n",
+__func__, mask);
+   return err;
+}
+
+
+/**
+ * It handles an IRQ-less transfer
+ * @i2c: ocores I2C device instance
+ *
+ * Even if IRQ are disabled, the I2C OpenCore IP behavior is exactly the same
+ * (only that IRQ are not produced). This means that we can re-use entirely
+ * ocores_isr(), we just add our polling code around it.
+ *
+ * It can run in atomic context
+ */
+static void ocores_process_polling(struct ocores_i2c *i2c)
+{
+   while (1) {
+   irqreturn_t ret;
+   int err;
+
+   err = ocores_poll_wait(i2c);
+   if (err) {
+   i2c->state = STATE_ERROR;
+   break; /* timeout */
+   }
+
+   ret = ocores_isr(-1, i2c);
+   if (ret == IRQ_NONE)
+   break; /* all messages have been transfered */
+   }
+}
+
+static int ocores_xfer_core(struct ocores_i2c *i2c,
+   struct i2c_msg *msgs, int num,
+   bool polling)
 {
-   struct ocores_i2c *i2c = i2c_get_adapdata(adap);
int ret;
+   u8 ctrl;
+
+   ctrl = oc_getreg(i2c, OCI2C_CONTROL);
+   if (polling)
+   oc_setreg(i2c, OCI2C_CONTROL, ctrl & ~OCI2C_CTRL_IEN);
+   else
+   oc_setreg(i2c, OCI2C_CONTROL, ctrl | OCI2C_CTRL_IEN);
 
i2c->msg = msgs;
i2c->pos = 0;
@@ -259,16 +367,37 @@ static int ocores_xfer(struct i2c_adapter *adap, struct 
i2c_msg *msgs, int num)
oc_setreg(i2c, OCI2C_DATA, i2c_8bit_addr_from_msg(i2c->msg));
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_START);
 
-   ret = wait_event_timeout(i2c->wait, (i2c->state == STATE_ERROR) ||
-(i2c->state == STATE_DONE), HZ);
-   if (ret == 0) {
-   ocores_process_timeout(i2c);

[PATCH v3 4/5] i2c:ocores: add SPDX tag

[Federico Vaga]

It adds the SPDX tag and it removes the old text about the GPLv2.

Signed-off-by: Federico Vaga 
---
 drivers/i2c/busses/i2c-ocores.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index bbe3e96..5b80190 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * i2c-ocores.c: I2C bus driver for OpenCores I2C controller
  * (https://opencores.org/project/i2c/overview)
@@ -7,9 +8,8 @@
  * Support for the GRLIB port of the controller by
  * Andreas Larsson 
  *
- * This file is licensed under the terms of the GNU General Public License
- * version 2.  This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
+ * This program is licensed "as is" without any warranty of any kind,
+ * whether express or implied.
  */
 
 #include 
-- 
2.15.0

[PATCH v3 5/5] i2c:ocores: checkpatch fixes

[Federico Vaga]

Miscellaneous style fixes from checkpatch

Signed-off-by: Federico Vaga 
---
 drivers/i2c/busses/i2c-ocores.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 5b80190..ba35d2a 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -182,8 +182,9 @@ static void ocores_process(struct ocores_i2c *i2c, u8 stat)
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
goto out;
}
-   } else
+   } else {
msg->buf[i2c->pos++] = oc_getreg(i2c, OCI2C_DATA);
+   }
 
/* end of msg? */
if (i2c->pos == msg->len) {
@@ -202,9 +203,9 @@ static void ocores_process(struct ocores_i2c *i2c, u8 stat)
oc_setreg(i2c, OCI2C_DATA, addr);
oc_setreg(i2c, OCI2C_CMD,  OCI2C_CMD_START);
goto out;
-   } else
-   i2c->state = (msg->flags & I2C_M_RD)
-   ? STATE_READ : STATE_WRITE;
+   }
+   i2c->state = (msg->flags & I2C_M_RD)
+   ? STATE_READ : STATE_WRITE;
} else {
i2c->state = STATE_DONE;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
@@ -405,7 +406,8 @@ static int ocores_init(struct device *dev, struct 
ocores_i2c *i2c)
u8 ctrl = oc_getreg(i2c, OCI2C_CONTROL);
 
/* make sure the device is disabled */
-   oc_setreg(i2c, OCI2C_CONTROL, ctrl & ~(OCI2C_CTRL_EN|OCI2C_CTRL_IEN));
+   ctrl &= ~(OCI2C_CTRL_EN | OCI2C_CTRL_IEN);
+   oc_setreg(i2c, OCI2C_CONTROL, ctrl);
 
prescale = (i2c->ip_clock_khz / (5 * i2c->bus_clock_khz)) - 1;
prescale = clamp(prescale, 0, 0x);
@@ -462,11 +464,13 @@ MODULE_DEVICE_TABLE(of, ocores_i2c_match);
 #ifdef CONFIG_OF
 /* Read and write functions for the GRLIB port of the controller. Registers are
  * 32-bit big endian and the PRELOW and PREHIGH registers are merged into one
- * register. The subsequent registers has their offset decreased accordingly. 
*/
+ * register. The subsequent registers has their offset decreased accordingly.
+ */
 static u8 oc_getreg_grlib(struct ocores_i2c *i2c, int reg)
 {
u32 rd;
int rreg = reg;
+
if (reg != OCI2C_PRELOW)
rreg--;
rd = ioread32be(i2c->base + (rreg << i2c->reg_shift));
@@ -480,6 +484,7 @@ static void oc_setreg_grlib(struct ocores_i2c *i2c, int 
reg, u8 value)
 {
u32 curr, wr;
int rreg = reg;
+
if (reg != OCI2C_PRELOW)
rreg--;
if (reg == OCI2C_PRELOW || reg == OCI2C_PREHIGH) {
@@ -568,7 +573,7 @@ static int ocores_i2c_of_probe(struct platform_device *pdev,
return 0;
 }
 #else
-#define ocores_i2c_of_probe(pdev,i2c) -ENODEV
+#define ocores_i2c_of_probe(pdev, i2c) -ENODEV
 #endif
 
 static int ocores_i2c_probe(struct platform_device *pdev)
-- 
2.15.0

[PATCH v3 1/5] i2c:ocores: stop transfer on timeout

[Federico Vaga]

Detecting a timeout is ok, but we also need to assert a STOP command on
the bus in order to prevent it from generating interrupts when there are
no on going transfers.

Example: very long transmission.

1. ocores_xfer: START a transfer
2. ocores_isr : handle byte by byte the transfer
3. ocores_xfer: goes in timeout [[bugfix here]]
4. ocores_xfer: return to I2C subsystem and to the I2C driver
5. I2C driver : it may clean up the i2c_msg memory
6. ocores_isr : receives another interrupt (pending bytes to be
transferred) but the i2c_msg memory is invalid now

So, since the transfer was too long, we have to detect the timeout and
STOP the transfer.

Another point is that we have a critical region here. When handling the
timeout condition we may have a running IRQ handler. For this reason I
introduce a spinlock.

In order to make easier to understan locking I have:
- added a new function to handle timeout
- modified the current ocores_process() function in order to be protected
  by the new spinlock
Like this it is obvious at first sight that this locking serializes
the execution of ocores_process() and ocores_process_timeout()

Signed-off-by: Federico Vaga 
---
 drivers/i2c/busses/i2c-ocores.c | 54 ++---
 1 file changed, 45 insertions(+), 9 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 87f9caa..aa85202 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -25,7 +25,12 @@
 #include 
 #include 
 #include 
+#include 
 
+/**
+ * @process_lock: protect I2C transfer process.
+ * ocores_process() and ocores_process_timeout() can't run in parallel.
+ */
 struct ocores_i2c {
void __iomem *base;
u32 reg_shift;
@@ -36,6 +41,7 @@ struct ocores_i2c {
int pos;
int nmsgs;
int state; /* see STATE_ */
+   spinlock_t process_lock;
struct clk *clk;
int ip_clock_khz;
int bus_clock_khz;
@@ -141,19 +147,26 @@ static void ocores_process(struct ocores_i2c *i2c)
 {
struct i2c_msg *msg = i2c->msg;
u8 stat = oc_getreg(i2c, OCI2C_STATUS);
+   unsigned long flags;
+
+   /*
+* If we spin here is because we are in timeout, so we are going
+* to be in STATE_ERROR. See ocores_process_timeout()
+*/
+   spin_lock_irqsave(>process_lock, flags);
 
if ((i2c->state == STATE_DONE) || (i2c->state == STATE_ERROR)) {
/* stop has been sent */
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_IACK);
wake_up(>wait);
-   return;
+   goto out;
}
 
/* error? */
if (stat & OCI2C_STAT_ARBLOST) {
i2c->state = STATE_ERROR;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
-   return;
+   goto out;
}
 
if ((i2c->state == STATE_START) || (i2c->state == STATE_WRITE)) {
@@ -163,7 +176,7 @@ static void ocores_process(struct ocores_i2c *i2c)
if (stat & OCI2C_STAT_NACK) {
i2c->state = STATE_ERROR;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
-   return;
+   goto out;
}
} else
msg->buf[i2c->pos++] = oc_getreg(i2c, OCI2C_DATA);
@@ -184,14 +197,14 @@ static void ocores_process(struct ocores_i2c *i2c)
 
oc_setreg(i2c, OCI2C_DATA, addr);
oc_setreg(i2c, OCI2C_CMD,  OCI2C_CMD_START);
-   return;
+   goto out;
} else
i2c->state = (msg->flags & I2C_M_RD)
? STATE_READ : STATE_WRITE;
} else {
i2c->state = STATE_DONE;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
-   return;
+   goto out;
}
}
 
@@ -202,6 +215,9 @@ static void ocores_process(struct ocores_i2c *i2c)
oc_setreg(i2c, OCI2C_DATA, msg->buf[i2c->pos++]);
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_WRITE);
}
+
+out:
+   spin_unlock_irqrestore(>process_lock, flags);
 }
 
 static irqreturn_t ocores_isr(int irq, void *dev_id)
@@ -213,9 +229,24 @@ static irqreturn_t ocores_isr(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+/**
+ * Process timeout event
+ * @i2c: ocores I2C device instance
+ */
+static void ocores_process_timeout(struct ocores_i2c *i2c)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>process_lock, flags);
+   i2c->state = STATE_ERROR;
+   oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
+   spin_unlock_irqrestore(>process_lock, flags);
+}
+
 static int ocores_xfer(struct i2c_adapter

[PATCH v3 0/5]

[Federico Vaga]

This patch set provides improvements to the i2c-ocore driver.

[V2 -> V3]
- fix error condition on platform_get_irq(). Copied from
  https://patchwork.ozlabs.org/patch/1038409/

[V1 -> V2]
- replaced usleep_range() with udelay() so that the polling version can be
  used in atomic context.
- added dedicated patch for minor style issues
- fixed delay computation
- use spin_lock_irqsave(), instead of spin_trylock_irqsave(). IACK is always
  necessary and a trylock would generate an extra interrupt for nothing
- make the driver ready for an eventual master_xfer_irqless()

[PATCH v3 2/5] i2c:ocores: do not handle IRQ if IF is not set

[Federico Vaga]

If the Interrupt Flag (IF) is not set, we should not handle the IRQ:
- the line can be shared with other devices
- it can be a spurious interrupt

To avoid reading twice the status register, the ocores_process() function
expects it to be read by the caller.

Signed-off-by: Federico Vaga 
Acked-by: Peter Korsgaard 
---
 drivers/i2c/busses/i2c-ocores.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index aa85202..fcc2558 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -143,10 +143,9 @@ static inline u8 oc_getreg(struct ocores_i2c *i2c, int reg)
return i2c->getreg(i2c, reg);
 }
 
-static void ocores_process(struct ocores_i2c *i2c)
+static void ocores_process(struct ocores_i2c *i2c, u8 stat)
 {
struct i2c_msg *msg = i2c->msg;
-   u8 stat = oc_getreg(i2c, OCI2C_STATUS);
unsigned long flags;
 
/*
@@ -223,8 +222,12 @@ out:
 static irqreturn_t ocores_isr(int irq, void *dev_id)
 {
struct ocores_i2c *i2c = dev_id;
+   u8 stat = oc_getreg(i2c, OCI2C_STATUS);
+
+   if (!(stat & OCI2C_STAT_IF))
+   return IRQ_NONE;
 
-   ocores_process(i2c);
+   ocores_process(i2c, stat);
 
return IRQ_HANDLED;
 }
-- 
2.15.0

[PATCH] doc:dmaengine: clarify DMA desc. pointer after submission

[Federico Vaga]

It clarifies that the DMA description pointer returned by
`dmaengine_prep_*` function should not be used after submission.

Signed-off-by: Federico Vaga 
---
 Documentation/driver-api/dmaengine/client.rst | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/driver-api/dmaengine/client.rst 
b/Documentation/driver-api/dmaengine/client.rst
index fbbb2831f29f..d728e50105eb 100644
--- a/Documentation/driver-api/dmaengine/client.rst
+++ b/Documentation/driver-api/dmaengine/client.rst
@@ -168,6 +168,13 @@ The details of these operations are:
dmaengine_submit() will not start the DMA operation, it merely adds
it to the pending queue. For this, see step 5, dma_async_issue_pending.
 
+   .. note::
+
+  After calling ``dmaengine_submit()`` the submitted transfer descriptor
+  (``struct dma_async_tx_descriptor``) belongs to the DMA engine.
+  Consequentially, the client must consider invalid the pointer to that
+  descriptor.
+
 5. Issue pending DMA requests and wait for callback notification
 
The transactions in the pending queue can be activated by calling the
-- 
2.15.0

Re: [PATCH] doc:it_IT: add translations in process/

[Federico Vaga]

On 2019-01-21 09:11, Federico Vaga wrote:

On Monday, January 21, 2019 2:56:17 AM CET Jonathan Corbet wrote:

On Sat, 19 Jan 2019 23:13:41 +0100

Federico Vaga  wrote:
> This patch adds the Italian translation for the following documents
> in Documentation/process:
>
> - applying-patches
> - submit-checklist
> - submitting-drivers
> - changes
> - stable api nonsense
>
> Signed-off-by: Federico Vaga 

In general, this looks good.  One thing jumped at me, though...(OK, 
more


than one, but only one to fix):
> +Perl
> +
> +
> +Per compilare il kernel vi servirà perl 5 e i seguenti moduli
> ``Getopt::Long``, +``Getopt::Std``, ``File::Basename``, e ``File::Find``.

Didn't Rob Landley go though some considerable pain a while back to
eliminate Perl from the basic kernel build?  This, perhaps, should 
come out
of the original.  (As long as it's still there, it makes sense to be 
in the

translation, of course).


I can have a deeper look and try to fix the original document too



> +Modifiche architetturali
> +
> +
> +DevFS è stato reso obsoleto da udev
> +(http://www.kernel.org/pub/linux/utils/kernel/hotplug/)
> +
> +Il supporto per UID a 32-bit è ora disponibile.  Divertitevi!

Speaking of stuff that should come out of the original...this is not
exactly news at this point...


Well, generally speaking this document mix things from the past and the
"present". Probably it requires a review.


I am having a look at this document and I am wandering if this is an 
useful
document? Clearly I see value in the table with all requirements 
summarised,

but I do not see it for the rest of the document.

So, I propose to actually rename change.rst to requirements.rst and 
remove

everything but the requirements chapter and the links.

(proposal)
Release changes probably need a CHANGELOG file, to describe new and
deprecated things.

And information about tools should be in other document.
(/proposal)

What do you think?


Meanwhile, here is the thing that actually needs to be fixed:
> +Raiserfsprogs
> +-
> +
> +Il pacchetto raiserfsprogs dovrebbe essere usato con raiserfs-3.6.x
> (Linux
> +kernel 2.4.x).  Questo è un pacchetto combinato che contiene versioni
> +funzionanti di ``mkreiserfs``, ``resize_reiserfs``, ``debugreiserfs`` e
> +``reiserfsck``.  Questi programmi funzionano sulle piattaforme i386 e
> alpha.
Even in Italian, I believe that 'Reiser" is spelled "Reiser"...


oops, your are right. I will fix this and send a V2 patch. Then I will 
have a

look at the original document and try to update it


Thanks,

jon


--
Federico Vaga
http://www.federicovaga.it/

[PATCH V3] doc:it_IT: add translations in process/

[Federico Vaga]

This patch adds the Italian translation for the following documents
in Documentation/process:

- applying-patches
- submit-checklist
- submitting-drivers
- changes
- stable api nonsense

Signed-off-by: Federico Vaga 
---

V3 - update according to recent change

8f7e6d134bda (doc/docs-next) doc: process: GPL -> GPL-compatible


 .../translations/it_IT/doc-guide/sphinx.rst   |   2 +
 .../it_IT/process/applying-patches.rst|  12 +-
 .../translations/it_IT/process/changes.rst| 487 +-
 .../it_IT/process/stable-api-nonsense.rst | 202 +++-
 .../it_IT/process/submit-checklist.rst| 127 -
 .../it_IT/process/submitting-drivers.rst  |   8 +-
 6 files changed, 822 insertions(+), 16 deletions(-)

diff --git a/Documentation/translations/it_IT/doc-guide/sphinx.rst 
b/Documentation/translations/it_IT/doc-guide/sphinx.rst
index 474b7e127893..793b5cc33403 100644
--- a/Documentation/translations/it_IT/doc-guide/sphinx.rst
+++ b/Documentation/translations/it_IT/doc-guide/sphinx.rst
@@ -3,6 +3,8 @@
 .. note:: Per leggere la documentazione originale in inglese:
  :ref:`Documentation/doc-guide/index.rst `
 
+.. _it_sphinxdoc:
+
 Introduzione
 
 
diff --git a/Documentation/translations/it_IT/process/applying-patches.rst 
b/Documentation/translations/it_IT/process/applying-patches.rst
index f5e9c7d0b16d..1d30e5cd2a3d 100644
--- a/Documentation/translations/it_IT/process/applying-patches.rst
+++ b/Documentation/translations/it_IT/process/applying-patches.rst
@@ -1,13 +1,15 @@
 .. include:: ../disclaimer-ita.rst
 
 :Original: :ref:`Documentation/process/applying-patches.rst `
-
+:Translator: Federico Vaga 
 
 .. _it_applying_patches:
 
-Applicare modifiche al kernel Linux
-===
+Applicare patch al kernel Linux

 
-.. warning::
+.. note::
 
-TODO ancora da tradurre
+   Questo documento è obsoleto.  Nella maggior parte dei casi, piuttosto
+   che usare ``patch`` manualmente, vorrete usare Git.  Per questo motivo
+   il documento non verrà tradotto.
diff --git a/Documentation/translations/it_IT/process/changes.rst 
b/Documentation/translations/it_IT/process/changes.rst
index 956cf95a1214..d0874327f301 100644
--- a/Documentation/translations/it_IT/process/changes.rst
+++ b/Documentation/translations/it_IT/process/changes.rst
@@ -1,12 +1,495 @@
 .. include:: ../disclaimer-ita.rst
 
 :Original: :ref:`Documentation/process/changes.rst `
+:Translator: Federico Vaga 
 
 .. _it_changes:
 
 Requisiti minimi per compilare il kernel
 
 
-.. warning::
+Introduzione
+
 
-TODO ancora da tradurre
+Questo documento fornisce una lista dei software necessari per eseguire i
+kernel 4.x.
+
+Questo documento è basato sul file "Changes" del kernel 2.0.x e quindi le
+persone che lo scrissero meritano credito (Jared Mauch, Axel Boldt,
+Alessandro Sigala, e tanti altri nella rete).
+
+Requisiti minimi correnti
+*
+
+Prima di pensare d'avere trovato un baco, aggiornate i seguenti programmi
+**almeno** alla versione indicata!  Se non siete certi della versione che state
+usando, il comando indicato dovrebbe dirvelo.
+
+Questa lista presume che abbiate già un kernel Linux funzionante.  In aggiunta,
+non tutti gli strumenti sono necessari ovunque; ovviamente, se non avete un
+modem ISDN, per esempio, probabilmente non dovreste preoccuparvi di
+isdn4k-utils.
+
+== =  

+Programma   Versione minima   Comando per verificare la 
versione
+== =  

+GNU C  4.6gcc --version
+GNU make   3.81   make --version
+binutils   2.20   ld -v
+flex   2.5.35 flex --version
+bison  2.0bison --version
+util-linux 2.10o  fdformat --version
+kmod   13 depmod -V
+e2fsprogs  1.41.4 e2fsck -V
+jfsutils   1.1.3  fsck.jfs -V
+reiserfsprogs  3.6.3  reiserfsck -V
+xfsprogs   2.6.0  xfs_db -V
+squashfs-tools 4.0mksquashfs -version
+btrfs-progs0.18   btrfsck
+pcmciautils004pccardctl -V
+quota-tools3.09   quota -V
+PPP2.4.0  pppd --version
+isdn4k-utils   3.1pre1isdnctrl 2>&1|grep version
+nfs-utils  1.0.5  showmount --version
+procps 3.2.0  ps --version
+oprofile   0.9oprofiled --version
+udev   081udevd --version
+grub   0.93 

Re: DMA Engine Documentation: TX Descriptor and Submission

[Federico Vaga]

On February 1, 2019 4:17:50 AM UTC, Vinod Koul  wrote:
>On 28-01-19, 09:47, Federico Vaga wrote:
>> Hi,
>> 
>> I have a new question concerning documentation.
>> 
>>
>https://www.kernel.org/doc/html/latest/driver-api/dmaengine/client.html
>> 
>> >From this document it is not really clear, at least to me, if
>clients can 
>> consider valid the `struct dma_async_tx_descriptor` after submission
>to the 
>> DMA engine.
>
>Nope they can't and should not touch the descriptor after submission.
>The client get cookie and that is supposed to be used

Good, thanks


>> 
>> Clients get a TX descriptor from a DMA engine using things like 
>> `dmaengine_prep_*`. These calls - may - allocate new descriptors and
>return 
>> them to the caller; this may include other structures which are not
>visible to 
>> clients. So, if my understanding is correct, this means that it's the
>DMA 
>> engine that, on TX completion, releases any TX descriptor allocated
>by 
>> `dmaengine_prep_*`. This implies that the pointer that the client is
>using 
>> must be considered invalid right after `dmaengine_submit()`.
>> If what I understood by reading the documentation and the code is
>correct, 
>> then I think that this should be mentioned in the Documentation.
>> If I'm wrong, please tell me where :)
>
>And what exactly are you trying to do here..?

What if I answer: "the right thing"? Joking. I just expressed my understanding 
of something which is not documented properly (my opinion). I wanted to be sure 
that the logic, the reasons behind are the ones that I understood. I will 
propose a patch to the documentation, unless you want to do it.
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.