Re: [PATCH v6 12/13] Documentation: remove stale firmware API reference

[Mauro Carvalho Chehab]

Em Tue,  8 May 2018 11:12:46 -0700
"Luis R. Rodriguez" <mcg...@kernel.org> escreveu:

> It refers to a pending patch, but this was merged eons ago.

Didn't know that such patch was already merged. Great!

Regards,
Mauro

> 
> Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org>
> ---
>  Documentation/dell_rbu.txt | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/Documentation/dell_rbu.txt b/Documentation/dell_rbu.txt
> index 0fdb6aa2704c..077fdc29a0d0 100644
> --- a/Documentation/dell_rbu.txt
> +++ b/Documentation/dell_rbu.txt
> @@ -121,9 +121,6 @@ read back the image downloaded.
>  
>  .. note::
>  
> -   This driver requires a patch for firmware_class.c which has the modified
> -   request_firmware_nowait function.
> -

> Also after updating the BIOS image a user mode application needs to 
> execute
> code which sends the BIOS update request to the BIOS. So on the next 
> reboot
> the BIOS knows about the new image downloaded and it updates itself.

You should likely remove the "Also" here.

With that,

Reviewed-by: Mauro Carvalho Chehab <mchehab+sams...@kernel.org>

Regards,
Mauro

Re: [PATCH v6 13/13] Documentation: clarify firmware_class provenance and why we can't rename the module

[Mauro Carvalho Chehab]

Em Tue,  8 May 2018 11:12:47 -0700
"Luis R. Rodriguez" <mcg...@kernel.org> escreveu:

> Clarify the provenance of the firmware loader firmware_class module name
> and why we cannot rename the module in the future.
> 
> Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org>
> ---
>  .../driver-api/firmware/fallback-mechanisms.rst  | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst 
> b/Documentation/driver-api/firmware/fallback-mechanisms.rst
> index a39323ef7d29..a8047be4a96e 100644
> --- a/Documentation/driver-api/firmware/fallback-mechanisms.rst
> +++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
> @@ -72,9 +72,12 @@ the firmware requested, and establishes it in the device 
> hierarchy by
>  associating the device used to make the request as the device's parent.
>  The sysfs directory's file attributes are defined and controlled through
>  the new device's class (firmware_class) and group (fw_dev_attr_groups).
> -This is actually where the original firmware_class.c file name comes from,
> -as originally the only firmware loading mechanism available was the
> -mechanism we now use as a fallback mechanism.
> +This is actually where the original firmware_class module name came from,
> +given that originally the only firmware loading mechanism available was the
> +mechanism we now use as a fallback mechanism, which which registers a
> +struct class firmware_class. Because the attributes exposed are part of the
> +module name, the module name firmware_class cannot be renamed in the future, 
> to
> +ensure backward compatibilty with old userspace.

Ah, now the explanation makes a lot more sense to me :-)

Reviewed-by: Mauro Carvalho Chehab <mchehab+sams...@kernel.org>

>  
>  To load firmware using the sysfs interface we expose a loading indicator,
>  and a file upload firmware into:



Thanks,
Mauro

Re: [PATCH 09/18] net: mac80211.h: fix a bad comment line

[Mauro Carvalho Chehab]

Em Mon, 07 May 2018 14:38:26 +0200
Johannes Berg <johan...@sipsolutions.net> escreveu:

> On Mon, 2018-05-07 at 15:37 +0300, Kalle Valo wrote:
> > Mauro Carvalho Chehab <mchehab+sams...@kernel.org> writes:
> >   
> > > Sphinx produces a lot of errors like this:
> > >   ./include/net/mac80211.h:2083: warning: bad line:  >
> > > 
> > > Signed-off-by: Mauro Carvalho Chehab <mchehab+sams...@kernel.org>  
> > 
> > Randy already submitted a similar patch:
> > 
> > https://patchwork.kernel.org/patch/10367275/
> > 
> > But it seems Johannes has not applied that yet.  
> 
> Yeah, I've been super busy preparing for the plugfest.
> 
> I'll make a pass over all the patches as soon as I can, hopefully today
> or tomorrow.

Thanks. I'll drop it from my patchset, assuming that you'll
be applying Randy's version or mine via your tree.

Thanks,
Mauro

[PATCH 00/18] Fix some build warnings/errors with Sphinx

[Mauro Carvalho Chehab]

I decided to give a try with Sphinx last stable version
(1.17.4), and noticed several issues. The worse one was
with the networking book: a non-standard footnote there
with [*] instead of a number causes it to break PDF building.

So, I took some spare time to address some warnings all over
the tree, and moved a few text documents to a book. I with
I had more time to move the other ones and to solve other
warnings.

Mauro Carvalho Chehab (18):
  docs: can.rst: fix a footnote reference
  docs: fix location of request_firmware & friends
  docs: */index.rst: Add newer documents to their respective index.rst
  docs: admin-guide: add bcache documentation
  docs: core-api: add cachetlb documentation
  docs: core-api: add cgroup-v2 documentation
  docs: core-api: add circular-buffers documentation
  docs: driver-api: add clk documentation
  net: mac80211.h: fix a bad comment line
  rcu: rcupdate.h: get rid of Sphinx warnings at rcu_pointer_handoff()
  docs: crypto_engine.rst: Fix two parse warnings
  time: timer.c: adjust a kernel-doc comment
  wait: wait.h: Get rid of a kernel-doc/Sphinx warnings
  fbdev: modedb.c: fix a kernel-doc markup
  iio: iio.h: use nested struct support on kernel-doc markup
  mtd: rawnand.h: use nested union kernel-doc markups
  docs: uio-howto.rst: use a code block to solve a warning
  w1: w1_io.c: fix a kernel-doc warning

 Documentation/00-INDEX| 10 ---
 .../{bcache.txt => admin-guide/bcache.rst}|  0
 .../cgroup-v2.rst}|  0
 Documentation/admin-guide/index.rst   |  2 ++
 .../admin-guide/kernel-parameters.txt |  2 +-
 .../{cachetlb.txt => core-api/cachetlb.rst}   |  0
 .../circular-buffers.rst} |  0
 Documentation/core-api/index.rst  |  2 ++
 Documentation/crypto/crypto_engine.rst|  8 +++---
 Documentation/crypto/index.rst|  1 +
 Documentation/dell_rbu.txt|  4 +--
 Documentation/{clk.txt => driver-api/clk.rst} |  0
 .../firmware/fallback-mechanisms.rst  |  2 +-
 .../driver-api/firmware/request_firmware.rst  | 17 +++-
 Documentation/driver-api/index.rst|  2 ++
 Documentation/driver-api/infrastructure.rst   |  2 +-
 Documentation/driver-api/uio-howto.rst|  3 ++-
 Documentation/memory-barriers.txt |  4 +--
 Documentation/networking/can.rst  |  4 +--
 .../power/suspend-and-cpuhotplug.txt  |  2 +-
 Documentation/process/index.rst   |  1 +
 Documentation/security/index.rst  |  2 ++
 .../translations/ko_KR/memory-barriers.txt|  4 +--
 drivers/video/fbdev/core/modedb.c | 22 
 drivers/w1/w1_io.c|  1 +
 include/linux/iio/iio.h   | 24 -
 include/linux/mtd/rawnand.h   | 26 +--
 include/linux/rcupdate.h  |  5 ++--
 include/linux/wait.h  |  2 +-
 include/net/mac80211.h|  2 +-
 kernel/time/timer.c   | 14 +-
 31 files changed, 93 insertions(+), 75 deletions(-)
 rename Documentation/{bcache.txt => admin-guide/bcache.rst} (100%)
 rename Documentation/{cgroup-v2.txt => admin-guide/cgroup-v2.rst} (100%)
 rename Documentation/{cachetlb.txt => core-api/cachetlb.rst} (100%)
 rename Documentation/{circular-buffers.txt => core-api/circular-buffers.rst} 
(100%)
 rename Documentation/{clk.txt => driver-api/clk.rst} (100%)

-- 
2.17.0

[PATCH 09/18] net: mac80211.h: fix a bad comment line

[Mauro Carvalho Chehab]

Sphinx produces a lot of errors like this:
./include/net/mac80211.h:2083: warning: bad line:  >

Signed-off-by: Mauro Carvalho Chehab <mchehab+sams...@kernel.org>
---
 include/net/mac80211.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index d2279b2d61aa..b2f3a0c018e7 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2080,7 +2080,7 @@ struct ieee80211_txq {
  * virtual interface might not be given air time for the transmission of
  * the frame, as it is not synced with the AP/P2P GO yet, and thus the
  * deauthentication frame might not be transmitted.
- >
+ *
  * @IEEE80211_HW_DOESNT_SUPPORT_QOS_NDP: The driver (or firmware) doesn't
  * support QoS NDP for AP probing - that's most likely a driver bug.
  *
-- 
2.17.0

Re: nested structs parsing

[Mauro Carvalho Chehab]

Em Thu, 29 Mar 2018 11:47:07 +0200
Johannes Berg  escreveu:

> On Thu, 2018-03-29 at 11:46 +0200, Johannes Berg wrote:
> > Hi,
> > 
> > For a while I haven't looked at my documentation for 802.11, and now I
> > noticed I'm getting warnings due to the nested parsing.
> > 
> > However, something seems to be wrong? I have, for example, this (in
> > net/mac80211/sta_info.h)
> > 
> > struct sta_info {
> > ...
> > struct {
> > u64 packets[IEEE80211_NUM_ACS];
> > u64 bytes[IEEE80211_NUM_ACS];
> > struct ieee80211_tx_rate last_rate;
> > u64 msdu[IEEE80211_NUM_TIDS + 1];
> > } tx_stats;
> > };
> > 
> > but I'm getting the following warnings now, with only "@tx_stats" being
> > described in the documentation:
> > 
> > net/mac80211/sta_info.h:590: warning: Function parameter or member 
> > 'status_stats.last_ack' not described in 'sta_info'
> > net/mac80211/sta_info.h:590: warning: Function parameter or member 
> > 'status_stats.last_ack_signal' not described in 'sta_info'
> > net/mac80211/sta_info.h:590: warning: Function parameter or member 
> > 'status_stats.ack_signal_filled' not described in 'sta_info'
> > net/mac80211/sta_info.h:590: warning: Function parameter or member 'msdu' 
> > not described in 'sta_info'
> > 
> > I can understand the first three of those, but not the last one? Why is
> > the last one not qualified?
> > 
> > If I change it to this:
> > 
> > struct {
> > u64 packets[IEEE80211_NUM_ACS];
> > u64 bytes[IEEE80211_NUM_ACS];
> > /**
> >  * @last_rate: last TX rate
> >  */
> > struct ieee80211_tx_rate last_rate;
> > /**
> >  * @msdu: # of MSDUs per TID
> >  */
> > u64 msdu[IEEE80211_NUM_TIDS + 1];
> > } tx_stats;
> > 
> > I still get a warning on "tx_stats.last_rate", but not on "msdu", which
> > is sort of obvious from the warning text, but also rather unexpected.
> > 
> > Normally I'd say that the "msdu" warning is originally wrong
> > 
> > However, I'd also argue that if I'm using inline declarations, I
> > shouldn't have to write it like this:
> > 
> > struct {
> > u64 packets[IEEE80211_NUM_ACS];
> > u64 bytes[IEEE80211_NUM_ACS];
> > /**
> >  * @tx_stats.last_rate: last TX rate
> >  */
> > struct ieee80211_tx_rate last_rate;
> > ...
> > } tx_stats;  
> 
> Whoops, sent a fraction of a second too early - this actually causes a
> warning too (no idea why four times):
> 
> net/mac80211/sta_info.h:560: warning: Incorrect use of kernel-doc format: 
>  * @tx_stats.last_rate: last TX rate
> net/mac80211/sta_info.h:560: warning: Incorrect use of kernel-doc format: 
>  * @tx_stats.last_rate: last TX rate
> net/mac80211/sta_info.h:560: warning: Incorrect use of kernel-doc format: 
>  * @tx_stats.last_rate: last TX rate
> net/mac80211/sta_info.h:560: warning: Incorrect use of kernel-doc format: 
>  * @tx_stats.last_rate: last TX rate

The original patchset for nested structs was supporting it only 
when not inlined. This should be fixed on this patchset:

https://lkml.org/lkml/2018/2/19/387

Do you have those patches on your tree?

With regards to duplicated warnings, that use to happen if the same header
is included several times (with is a common pratice at the net subsystem).

I also submitted some patches to linux-next addressing it.

Could you please merge from docs-next and see if those problems
get solved?

It is located at:

git://git.lwn.net/linux.git docs-next

Thanks,
Mauro

Re: [PATCH 00/18] use ARRAY_SIZE macro

[Mauro Carvalho Chehab]

Em Sun, 1 Oct 2017 20:52:20 -0400
Jérémy Lefaure  escreveu:

> Anyway, I can tell to each maintainer that they can apply the patches
> they're concerned about and next time I may send individual patches.

In the case of media, we'll handle it as if they were individual ones.

Thanks,
Mauro

[PATCH v2 07/26] rfkill.txt: standardize document format

[Mauro Carvalho Chehab]

Each text file under Documentation follows a different
format. Some doesn't even have titles!

Change its representation to follow the adopted standard,
using ReST markups for it to be parseable by Sphinx:

- mark titles;
- comment contents index;
- mark literal blocks;
- adjust identation.

Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
---
 Documentation/rfkill.txt | 43 ++-
 1 file changed, 26 insertions(+), 17 deletions(-)

diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
index 8c174063b3f0..a289285d2412 100644
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt
@@ -1,13 +1,13 @@
+===
 rfkill - RF kill switch support
 ===
 
-1. Introduction
-2. Implementation details
-3. Kernel API
-4. Userspace support
 
+.. contents::
+   :depth: 2
 
-1. Introduction
+Introduction
+
 
 The rfkill subsystem provides a generic interface to disabling any radio
 transmitter in the system. When a transmitter is blocked, it shall not
@@ -21,17 +21,24 @@ aircraft.
 The rfkill subsystem has a concept of "hard" and "soft" block, which
 differ little in their meaning (block == transmitters off) but rather in
 whether they can be changed or not:
- - hard block: read-only radio block that cannot be overridden by software
- - soft block: writable radio block (need not be readable) that is set by
-   the system software.
+
+ - hard block
+   read-only radio block that cannot be overridden by software
+
+ - soft block
+   writable radio block (need not be readable) that is set by
+the system software.
 
 The rfkill subsystem has two parameters, rfkill.default_state and
-rfkill.master_switch_mode, which are documented in 
admin-guide/kernel-parameters.rst.
+rfkill.master_switch_mode, which are documented in
+admin-guide/kernel-parameters.rst.
 
 
-2. Implementation details
+Implementation details
+==
 
 The rfkill subsystem is composed of three main components:
+
  * the rfkill core,
  * the deprecated rfkill-input module (an input layer handler, being
replaced by userspace policy code) and
@@ -55,7 +62,8 @@ use the return value of rfkill_set_hw_state() unless the 
hardware actually
 keeps track of soft and hard block separately.
 
 
-3. Kernel API
+Kernel API
+==
 
 
 Drivers for radio transmitters normally implement an rfkill driver.
@@ -69,7 +77,7 @@ For some platforms, it is possible that the hardware state 
changes during
 suspend/hibernation, in which case it will be necessary to update the rfkill
 core with the current state is at resume time.
 
-To create an rfkill driver, driver's Kconfig needs to have
+To create an rfkill driver, driver's Kconfig needs to have::
 
depends on RFKILL || !RFKILL
 
@@ -87,7 +95,8 @@ RFKill provides per-switch LED triggers, which can be used to 
drive LEDs
 according to the switch state (LED_FULL when blocked, LED_OFF otherwise).
 
 
-5. Userspace support
+Userspace support
+=
 
 The recommended userspace interface to use is /dev/rfkill, which is a misc
 character device that allows userspace to obtain and set the state of rfkill
@@ -112,11 +121,11 @@ rfkill core framework.
 Additionally, each rfkill device is registered in sysfs and emits uevents.
 
 rfkill devices issue uevents (with an action of "change"), with the following
-environment variables set:
+environment variables set::
 
-RFKILL_NAME
-RFKILL_STATE
-RFKILL_TYPE
+   RFKILL_NAME
+   RFKILL_STATE
+   RFKILL_TYPE
 
 The contents of these variables corresponds to the "name", "state" and
 "type" sysfs files explained above.
-- 
2.9.4

[PATCH 00/29] Standardize doc formats - part 3

[Mauro Carvalho Chehab]

Each document under Documentation/*.txt has its own format.
Some follow markup notations, some don't even have a title!

In order to try to get some order on it, change the document
style to the standard we're adopting after the adoption of
ReStructured Text.

The documents touched on this series now build fine with
Sphinx, if renamed to *.rst extension.

The main goal with this is to teach people by example about
what format is expected on newer documents. It also helps
to add those files to Kernel books.

In order to make things more palatable, I'm spliting the
conversion into three parts.

This is part 3.

Mauro Carvalho Chehab (29):
  pinctrl.txt: standardize document format
  pnp.txt: standardize document format
  preempt-locking.txt: standardize document format
  printk-formats.txt: standardize document format
  pwm.txt: standardize document format
  rbtree.txt: standardize document format
  remoteproc.txt: standardize document format
  rfkill.txt: standardize document format
  robust-futex-ABI.txt: standardize document format
  robust-futexes.txt: standardize document format
  rpmsg.txt: standardize document format
  rtc.txt: standardize document format
  SAK.txt: standardize document format
  sgi-ioc4.txt: standardize document format
  siphash.txt: standardize document format
  SM501.txt: standardize document format
  smsc_ece1099.txt: standardize document format
  static-keys.txt: standardize document format
  svga.txt: standardize document format
  sync_file.txt: standardize document format
  this_cpu_ops.txt: standardize document format
  unaligned-memory-access.txt: standardize document format
  vfio-mediated-device.txt: standardize document format
  vfio.txt: standardize document format
  video-output.txt: standardize document format
  xillybus.txt: standardize document format
  xz.txt: standardize document format
  zorro.txt: standardize document format
  dell_rbu.txt: standardize document format

 Documentation/SAK.txt |   65 +-
 Documentation/SM501.txt   |9 +-
 Documentation/dell_rbu.txt|   81 ++-
 Documentation/pinctrl.txt | 1104 +++--
 Documentation/pnp.txt |  343 +
 Documentation/preempt-locking.txt |   40 +-
 Documentation/printk-formats.txt  |  416 ++-
 Documentation/pwm.txt |   46 +-
 Documentation/rbtree.txt  |   88 +--
 Documentation/remoteproc.txt  |  320 +
 Documentation/rfkill.txt  |   47 +-
 Documentation/robust-futex-ABI.txt|   14 +-
 Documentation/robust-futexes.txt  |   12 +-
 Documentation/rpmsg.txt   |  340 +
 Documentation/rtc.txt |   44 +-
 Documentation/sgi-ioc4.txt|4 +
 Documentation/siphash.txt |  186 ++---
 Documentation/smsc_ece1099.txt|4 +
 Documentation/static-keys.txt |  199 +++---
 Documentation/svga.txt|  146 ++--
 Documentation/sync_file.txt   |   23 +-
 Documentation/this_cpu_ops.txt|   49 +-
 Documentation/unaligned-memory-access.txt |   57 +-
 Documentation/vfio-mediated-device.txt|  252 +++
 Documentation/vfio.txt|  261 +++
 Documentation/video-output.txt|   54 +-
 Documentation/xillybus.txt|   29 +-
 Documentation/xz.txt  |  182 ++---
 Documentation/zorro.txt   |   59 +-
 29 files changed, 2437 insertions(+), 2037 deletions(-)

-- 
2.9.4

[PATCH 08/29] rfkill.txt: standardize document format

[Mauro Carvalho Chehab]

Each text file under Documentation follows a different
format. Some doesn't even have titles!

Change its representation to follow the adopted standard,
using ReST markups for it to be parseable by Sphinx:

- mark titles;
- comment contents index;
- mark literal blocks;
- adjust identation.

Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
---
 Documentation/rfkill.txt | 47 ++-
 1 file changed, 30 insertions(+), 17 deletions(-)

diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
index 8c174063b3f0..d22feccedbd1 100644
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt
@@ -1,13 +1,17 @@
+===
 rfkill - RF kill switch support
 ===
 
-1. Introduction
-2. Implementation details
-3. Kernel API
-4. Userspace support
+.. CONTENTS
 
+  1. Introduction
+  2. Implementation details
+  3. Kernel API
+  4. Userspace support
 
-1. Introduction
+
+Introduction
+
 
 The rfkill subsystem provides a generic interface to disabling any radio
 transmitter in the system. When a transmitter is blocked, it shall not
@@ -21,17 +25,24 @@ aircraft.
 The rfkill subsystem has a concept of "hard" and "soft" block, which
 differ little in their meaning (block == transmitters off) but rather in
 whether they can be changed or not:
- - hard block: read-only radio block that cannot be overridden by software
- - soft block: writable radio block (need not be readable) that is set by
-   the system software.
+
+ - hard block
+   read-only radio block that cannot be overridden by software
+
+ - soft block
+   writable radio block (need not be readable) that is set by
+the system software.
 
 The rfkill subsystem has two parameters, rfkill.default_state and
-rfkill.master_switch_mode, which are documented in 
admin-guide/kernel-parameters.rst.
+rfkill.master_switch_mode, which are documented in
+admin-guide/kernel-parameters.rst.
 
 
-2. Implementation details
+Implementation details
+==
 
 The rfkill subsystem is composed of three main components:
+
  * the rfkill core,
  * the deprecated rfkill-input module (an input layer handler, being
replaced by userspace policy code) and
@@ -55,7 +66,8 @@ use the return value of rfkill_set_hw_state() unless the 
hardware actually
 keeps track of soft and hard block separately.
 
 
-3. Kernel API
+Kernel API
+==
 
 
 Drivers for radio transmitters normally implement an rfkill driver.
@@ -69,7 +81,7 @@ For some platforms, it is possible that the hardware state 
changes during
 suspend/hibernation, in which case it will be necessary to update the rfkill
 core with the current state is at resume time.
 
-To create an rfkill driver, driver's Kconfig needs to have
+To create an rfkill driver, driver's Kconfig needs to have::
 
depends on RFKILL || !RFKILL
 
@@ -87,7 +99,8 @@ RFKill provides per-switch LED triggers, which can be used to 
drive LEDs
 according to the switch state (LED_FULL when blocked, LED_OFF otherwise).
 
 
-5. Userspace support
+Userspace support
+=
 
 The recommended userspace interface to use is /dev/rfkill, which is a misc
 character device that allows userspace to obtain and set the state of rfkill
@@ -112,11 +125,11 @@ rfkill core framework.
 Additionally, each rfkill device is registered in sysfs and emits uevents.
 
 rfkill devices issue uevents (with an action of "change"), with the following
-environment variables set:
+environment variables set::
 
-RFKILL_NAME
-RFKILL_STATE
-RFKILL_TYPE
+   RFKILL_NAME
+   RFKILL_STATE
+   RFKILL_TYPE
 
 The contents of these variables corresponds to the "name", "state" and
 "type" sysfs files explained above.
-- 
2.9.4

Re: [PATCH] drivers: misc: ti-st: Use int instead of fuzzy char for callback status

[Mauro Carvalho Chehab]

Em Mon,  6 Jun 2016 11:02:03 +0200
Geert Uytterhoeven <ge...@linux-m68k.org> escreveu:

> On mips and parisc:
> 
> drivers/bluetooth/btwilink.c: In function 'ti_st_open':
> drivers/bluetooth/btwilink.c:174:21: warning: overflow in implicit 
> constant conversion [-Woverflow]
>hst->reg_status = -EINPROGRESS;
> 
> drivers/nfc/nfcwilink.c: In function 'nfcwilink_open':
> drivers/nfc/nfcwilink.c:396:31: warning: overflow in implicit constant 
> conversion [-Woverflow]
>   drv->st_register_cb_status = -EINPROGRESS;
> 
> There are actually two issues:
>   1. Whether "char" is signed or unsigned depends on the architecture.
>  As the completion callback data is used to pass a (negative) error
>  code, it should always be signed.
>   2. EINPROGRESS is 150 on mips, 245 on parisc.
>  Hence -EINPROGRESS doesn't fit in a signed 8-bit number.
> 
> Change the callback status from "char" to "int" to fix these.
> 
> Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>

Patch looks sane to me, but who will apply it?

Anyway:

Acked-by: Mauro Carvalho Chehab <mche...@s-opensource.com>


> ---
> Compile-tested only.
> ---
>  drivers/bluetooth/btwilink.c  | 4 ++--
>  drivers/media/radio/wl128x/fmdrv_common.c | 2 +-
>  drivers/misc/ti-st/st_core.c  | 2 +-
>  drivers/nfc/nfcwilink.c   | 4 ++--
>  include/linux/ti_wilink_st.h  | 2 +-
>  5 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/bluetooth/btwilink.c b/drivers/bluetooth/btwilink.c
> index 24a652f9252be899..485281b3f1677678 100644
> --- a/drivers/bluetooth/btwilink.c
> +++ b/drivers/bluetooth/btwilink.c
> @@ -51,7 +51,7 @@
>   */
>  struct ti_st {
>   struct hci_dev *hdev;
> - char reg_status;
> + int reg_status;
>   long (*st_write) (struct sk_buff *);
>   struct completion wait_reg_completion;
>  };
> @@ -83,7 +83,7 @@ static inline void ti_st_tx_complete(struct ti_st *hst, int 
> pkt_type)
>   * status.ti_st_open() function will wait for signal from this
>   * API when st_register() function returns ST_PENDING.
>   */
> -static void st_reg_completion_cb(void *priv_data, char data)
> +static void st_reg_completion_cb(void *priv_data, int data)
>  {
>   struct ti_st *lhst = priv_data;
>  
> diff --git a/drivers/media/radio/wl128x/fmdrv_common.c 
> b/drivers/media/radio/wl128x/fmdrv_common.c
> index 3f9e6df7d837ac27..642b89c66bcb99eb 100644
> --- a/drivers/media/radio/wl128x/fmdrv_common.c
> +++ b/drivers/media/radio/wl128x/fmdrv_common.c
> @@ -1472,7 +1472,7 @@ static long fm_st_receive(void *arg, struct sk_buff 
> *skb)
>   * Called by ST layer to indicate protocol registration completion
>   * status.
>   */
> -static void fm_st_reg_comp_cb(void *arg, char data)
> +static void fm_st_reg_comp_cb(void *arg, int data)
>  {
>   struct fmdev *fmdev;
>  
> diff --git a/drivers/misc/ti-st/st_core.c b/drivers/misc/ti-st/st_core.c
> index dcdbd58672ccc6d2..00051590e00f9647 100644
> --- a/drivers/misc/ti-st/st_core.c
> +++ b/drivers/misc/ti-st/st_core.c
> @@ -141,7 +141,7 @@ static void st_send_frame(unsigned char chnl_id, struct 
> st_data_s *st_gdata)
>   * This function is being called with spin lock held, protocol drivers are
>   * only expected to complete their waits and do nothing more than that.
>   */
> -static void st_reg_complete(struct st_data_s *st_gdata, char err)
> +static void st_reg_complete(struct st_data_s *st_gdata, int err)
>  {
>   unsigned char i = 0;
>   pr_info(" %s ", __func__);
> diff --git a/drivers/nfc/nfcwilink.c b/drivers/nfc/nfcwilink.c
> index f81e500e765061fd..3fbd18b8e473f696 100644
> --- a/drivers/nfc/nfcwilink.c
> +++ b/drivers/nfc/nfcwilink.c
> @@ -94,7 +94,7 @@ struct nfcwilink {
>   struct nci_dev  *ndev;
>   unsigned long   flags;
>  
> - charst_register_cb_status;
> + int st_register_cb_status;
>   long(*st_write) (struct sk_buff *);
>  
>   struct completion   completed;
> @@ -320,7 +320,7 @@ exit:
>  }
>  
>  /* Called by ST when registration is complete */
> -static void nfcwilink_register_complete(void *priv_data, char data)
> +static void nfcwilink_register_complete(void *priv_data, int data)
>  {
>   struct nfcwilink *drv = priv_data;
>  
> diff --git a/include/linux/ti_wilink_st.h b/include/linux/ti_wilink_st.h
> index 0a0d56834c8eb412..f2293028ab9d65e6 100644
> --- a/include/linux/ti_wilink_st.h
> +++ b/include/linux/ti_wi

Re: [PATCH] treewide: Fix typo compatability - compatibility

[Mauro Carvalho Chehab]

Em Wed, 27 May 2015 15:05:42 +0300
Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu:

 Even though 'compatability' has a dedicated entry in the Wiktionary,
 it's listed as 'Mispelling of compatibility'. Fix it.
 
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com

 ---
  arch/metag/include/asm/elf.h | 2 +-
  arch/powerpc/kvm/book3s.c| 2 +-
  arch/sparc/include/uapi/asm/pstate.h | 2 +-
  drivers/gpu/drm/drm_atomic_helper.c  | 4 ++--
  drivers/media/dvb-frontends/au8522_dig.c | 2 +-
  drivers/net/wireless/ipw2x00/ipw2100.h   | 2 +-
  6 files changed, 7 insertions(+), 7 deletions(-)
 
 I can split this into one patch per subsystem, but that seems a bit overkill.
 Can someone take it ?

Who? That's the problem with treewide patches ;) 

Perhaps you should re-submit it with the acks you got to akpm.

Regards,
Mauro

 
 diff --git a/arch/metag/include/asm/elf.h b/arch/metag/include/asm/elf.h
 index d2baf6961794..87b0cf1e0acb 100644
 --- a/arch/metag/include/asm/elf.h
 +++ b/arch/metag/include/asm/elf.h
 @@ -11,7 +11,7 @@
  #define R_METAG_RELBRANCH4
  #define R_METAG_GETSETOFF5
  
 -/* Backward compatability */
 +/* Backward compatibility */
  #define R_METAG_REG32OP1 6
  #define R_METAG_REG32OP2 7
  #define R_METAG_REG32OP3 8
 diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
 index 453a8a47a467..cb14dd78a2e7 100644
 --- a/arch/powerpc/kvm/book3s.c
 +++ b/arch/powerpc/kvm/book3s.c
 @@ -901,7 +901,7 @@ int kvmppc_core_check_processor_compat(void)
  {
   /*
* We always return 0 for book3s. We check
 -  * for compatability while loading the HV
 +  * for compatibility while loading the HV
* or PR module
*/
   return 0;
 diff --git a/arch/sparc/include/uapi/asm/pstate.h 
 b/arch/sparc/include/uapi/asm/pstate.h
 index 4b6b998afd99..cf832e14aa05 100644
 --- a/arch/sparc/include/uapi/asm/pstate.h
 +++ b/arch/sparc/include/uapi/asm/pstate.h
 @@ -88,7 +88,7 @@
  #define VERS_MAXTL   _AC(0xff00,UL) /* Max Trap Level.   */
  #define VERS_MAXWIN  _AC(0x001f,UL) /* Max RegWindow Idx.*/
  
 -/* Compatability Feature Register (%asr26), SPARC-T4 and later  */
 +/* Compatibility Feature Register (%asr26), SPARC-T4 and later  */
  #define CFR_AES  _AC(0x0001,UL) /* Supports AES 
 opcodes */
  #define CFR_DES  _AC(0x0002,UL) /* Supports DES 
 opcodes */
  #define CFR_KASUMI   _AC(0x0004,UL) /* Supports KASUMI opcodes  
 */
 diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
 b/drivers/gpu/drm/drm_atomic_helper.c
 index b82ef6262469..12c5b79b0e8f 100644
 --- a/drivers/gpu/drm/drm_atomic_helper.c
 +++ b/drivers/gpu/drm/drm_atomic_helper.c
 @@ -751,7 +751,7 @@ crtc_set_mode(struct drm_device *dev, struct 
 drm_atomic_state *old_state)
   * This function shuts down all the outputs that need to be shut down and
   * prepares them (if required) with the new mode.
   *
 - * For compatability with legacy crtc helpers this should be called before
 + * For compatibility with legacy crtc helpers this should be called before
   * drm_atomic_helper_commit_planes(), which is what the default commit 
 function
   * does. But drivers with different needs can group the modeset commits 
 together
   * and do the plane commits at the end. This is useful for drivers doing 
 runtime
 @@ -776,7 +776,7 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_modeset_disables);
   * This function enables all the outputs with the new configuration which 
 had to
   * be turned off for the update.
   *
 - * For compatability with legacy crtc helpers this should be called after
 + * For compatibility with legacy crtc helpers this should be called after
   * drm_atomic_helper_commit_planes(), which is what the default commit 
 function
   * does. But drivers with different needs can group the modeset commits 
 together
   * and do the plane commits at the end. This is useful for drivers doing 
 runtime
 diff --git a/drivers/media/dvb-frontends/au8522_dig.c 
 b/drivers/media/dvb-frontends/au8522_dig.c
 index 5d06c99b0e97..edadcc7eea6c 100644
 --- a/drivers/media/dvb-frontends/au8522_dig.c
 +++ b/drivers/media/dvb-frontends/au8522_dig.c
 @@ -922,7 +922,7 @@ module_param(debug, int, 0644);
  MODULE_PARM_DESC(debug, Enable verbose debug messages);
  
  module_param(zv_mode, int, 0644);
 -MODULE_PARM_DESC(zv_mode, Turn on/off ZeeVee modulator compatability mode 
 (default:on).\n
 +MODULE_PARM_DESC(zv_mode, Turn on/off ZeeVee modulator compatibility mode 
 (default:on).\n
   \t\ton - modified AU8522 QAM256 initialization.\n
   \t\tProvides faster lock when using ZeeVee modulator based sources);
  
 diff --git a/drivers/net/wireless/ipw2x00/ipw2100.h 
 b/drivers/net/wireless/ipw2x00/ipw2100.h
 index c6d78790cb0d..193947865efd