Re: [PATCH v6 12/13] Documentation: remove stale firmware API reference
Em Tue, 8 May 2018 11:12:46 -0700 "Luis R. Rodriguez" 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 > --- > 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 Regards, Mauro
Re: [PATCH v6 13/13] Documentation: clarify firmware_class provenance and why we can't rename the module
Em Tue, 8 May 2018 11:12:47 -0700 "Luis R. Rodriguez" 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 > --- > .../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 > > 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
Em Mon, 07 May 2018 14:38:26 +0200 Johannes Berg escreveu: > On Mon, 2018-05-07 at 15:37 +0300, Kalle Valo wrote: > > Mauro Carvalho Chehab writes: > > > > > Sphinx produces a lot of errors like this: > > > ./include/net/mac80211.h:2083: warning: bad line: > > > > > > > Signed-off-by: Mauro Carvalho Chehab > > > > 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
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
Sphinx produces a lot of errors like this:
./include/net/mac80211.h:2083: warning: bad line: >
Signed-off-by: Mauro Carvalho Chehab
---
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
Em Thu, 29 Mar 2018 16:26:33 +0200
Johannes Berg escreveu:
> Hi,
>
> > 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?
>
> No, looks like I don't have those yet. I'll wait for those then.
>
> > 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).
>
> Yeah, doesn't really matter anyway. I think I have to, in a sense,
> because I'm getting lots of functions separately from the headers.
>
> > Could you please merge from docs-next and see if those problems
> > get solved?
>
> No, that doesn't seem to address it fully:
>
> net/mac80211/sta_info.h:586: warning: Function parameter or member
> 'tx_stats.packets' not described in 'sta_info'
> net/mac80211/sta_info.h:586: warning: Function parameter or member
> 'tx_stats.bytes' not described in 'sta_info'
> net/mac80211/sta_info.h:586: warning: Function parameter or member
> 'tx_stats.last_rate' not described in 'sta_info'
> net/mac80211/sta_info.h:586: warning: Function parameter or member 'msdu' not
> described in 'sta_info'
>
> You can reproduce this in
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git master
>
> (merging with docs-next) and running
>
> make SPHINXDIRS=driver-api/80211 htmldocs
No need to run it for checking the errors... you can run just:
./scripts/kernel-doc -none net/mac80211/sta_info.h
Applying the enclosed patch seems to work:
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index f64eb86ca64b..d81cb6155e8d 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -477,6 +477,10 @@ struct ieee80211_sta_rx_stats {
* @tdls_chandef: a TDLS peer can have a wider chandef that is compatible to
* the BSS one.
* @tx_stats: TX statistics
+ * @tx_stats.packets: foo
+ * @tx_stats.last_rate: bar
+ * @tx_stats.bytes: foobar
+ * @tx_stats.msdu: foo
* @rx_stats: RX statistics
* @pcpu_rx_stats: per-CPU RX statistics, assigned only if the driver needs
* this (by advertising the USES_RSS hw flag)
What's weird is that tx_stats.msdu field seems to be parsed wrong.
I'll take a look on it.
Thanks,
Mauro
Re: nested structs parsing
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: [trivial PATCH] treewide: Align function definition open/close braces
Em Sun, 17 Dec 2017 16:28:44 -0800
Joe Perches escreveu:
> Some functions definitions have either the initial open brace and/or
> the closing brace outside of column 1.
>
> Move those braces to column 1.
>
> This allows various function analyzers like gnu complexity to work
> properly for these modified functions.
>
> Miscellanea:
>
> o Remove extra trailing ; and blank line from xfs_agf_verify
>
> Signed-off-by: Joe Perches
For the media patch:
Acked-by: Mauro Carvalho Chehab
> ---
> git diff -w shows no difference other than the above 'Miscellanea'
>
> (this is against -next, but it applies against Linus' tree
> with a couple offsets)
>
> arch/x86/include/asm/atomic64_32.h | 2 +-
> drivers/acpi/custom_method.c | 2 +-
> drivers/acpi/fan.c | 2 +-
> drivers/gpu/drm/amd/display/dc/core/dc.c | 2 +-
> drivers/media/i2c/msp3400-kthreads.c | 2 +-
> drivers/message/fusion/mptsas.c | 2 +-
> drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c | 2 +-
> drivers/net/wireless/ath/ath9k/xmit.c| 2 +-
> drivers/platform/x86/eeepc-laptop.c | 2 +-
> drivers/rtc/rtc-ab-b5ze-s3.c | 2 +-
> drivers/scsi/dpt_i2o.c | 2 +-
> drivers/scsi/sym53c8xx_2/sym_glue.c | 2 +-
> fs/locks.c | 2 +-
> fs/ocfs2/stack_user.c| 2 +-
> fs/xfs/libxfs/xfs_alloc.c| 5 ++---
> fs/xfs/xfs_export.c | 2 +-
> kernel/audit.c | 6 +++---
> kernel/trace/trace_printk.c | 4 ++--
> lib/raid6/sse2.c | 14 +++---
> sound/soc/fsl/fsl_dma.c | 2 +-
> 20 files changed, 30 insertions(+), 31 deletions(-)
>
> diff --git a/arch/x86/include/asm/atomic64_32.h
> b/arch/x86/include/asm/atomic64_32.h
> index 97c46b8169b7..d4d4883080fa 100644
> --- a/arch/x86/include/asm/atomic64_32.h
> +++ b/arch/x86/include/asm/atomic64_32.h
> @@ -122,7 +122,7 @@ static inline long long atomic64_read(const atomic64_t *v)
> long long r;
> alternative_atomic64(read, "=&A" (r), "c" (v) : "memory");
> return r;
> - }
> +}
>
> /**
> * atomic64_add_return - add and return
> diff --git a/drivers/acpi/custom_method.c b/drivers/acpi/custom_method.c
> index c68e72414a67..e967c1173ba3 100644
> --- a/drivers/acpi/custom_method.c
> +++ b/drivers/acpi/custom_method.c
> @@ -94,7 +94,7 @@ static void __exit acpi_custom_method_exit(void)
> {
> if (cm_dentry)
> debugfs_remove(cm_dentry);
> - }
> +}
>
> module_init(acpi_custom_method_init);
> module_exit(acpi_custom_method_exit);
> diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c
> index 6cf4988206f2..3563103590c6 100644
> --- a/drivers/acpi/fan.c
> +++ b/drivers/acpi/fan.c
> @@ -219,7 +219,7 @@ fan_set_cur_state(struct thermal_cooling_device *cdev,
> unsigned long state)
> return fan_set_state_acpi4(device, state);
> else
> return fan_set_state(device, state);
> - }
> +}
>
> static const struct thermal_cooling_device_ops fan_cooling_ops = {
> .get_max_state = fan_get_max_state,
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index d1488d5ee028..1e0d1e7c5324 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -461,7 +461,7 @@ static void disable_dangling_plane(struct dc *dc, struct
> dc_state *context)
>
> **/
>
> struct dc *dc_create(const struct dc_init_data *init_params)
> - {
> +{
> struct dc *dc = kzalloc(sizeof(*dc), GFP_KERNEL);
> unsigned int full_pipe_count;
>
> diff --git a/drivers/media/i2c/msp3400-kthreads.c
> b/drivers/media/i2c/msp3400-kthreads.c
> index 4dd01e9f553b..dc6cb8d475b3 100644
> --- a/drivers/media/i2c/msp3400-kthreads.c
> +++ b/drivers/media/i2c/msp3400-kthreads.c
> @@ -885,7 +885,7 @@ static int msp34xxg_modus(struct i2c_client *client)
> }
>
> static void msp34xxg_set_source(struct i2c_client *client, u16 reg, int in)
> - {
> +{
> struct msp_state *state = to_state(i2c_get_clientdata(client));
> int source, matrix;
>
> diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion
Re: [PATCH 00/18] use ARRAY_SIZE macro
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
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 --- 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
Re: [PATCH 08/29] rfkill.txt: standardize document format
Em Fri, 19 May 2017 12:15:01 +0200 Johannes Berg escreveu: > On Thu, 2017-05-18 at 22:25 -0300, Mauro Carvalho Chehab wrote: > > > > +.. CONTENTS > > > > + 1. Introduction > > + 2. Implementation details > > + 3. Kernel API > > + 4. Userspace support > > Why not let this be auto-generated? > > .. contents:: >:depth: 1 > > should work, no? Yes, it should work. Actually, you would need to use :depth: 2 to produce this output: Contents . rfkill - RF kill switch support . Introduction . Implementation details . Kernel API . Userspace support I opted to keep the contents as a comment just because, in the past, some maintainers complained about TOC removal, arguing that it makes harder for the ones that would be reading the file in ascii. Thanks, Mauro
[PATCH 00/29] Standardize doc formats - part 3
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
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 --- 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
Em Mon, 6 Jun 2016 11:02:03 +0200
Geert Uytterhoeven 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
Patch looks sane to me, but who will apply it?
Anyway:
Acked-by: Mauro Carvalho Chehab
> ---
> 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_wilink_st.h
> @@ -71,7 +71,7 @@ struct st_proto_s {
> enum proto_ty
Re: [PATCH] treewide: Fix typo compatability -> compatibility
Em Wed, 27 May 2015 15:05:42 +0300
Laurent Pinchart 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
Acked-by: Mauro Carvalho Chehab
> ---
> 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
