* Re: [PATCH 03/10] mfd / platform: cros_ec: Miscellaneous character device to talk with the EC
From: Greg Kroah-Hartman @ 2019-06-04 18:59 UTC (permalink / raw)
To: Guenter Roeck
Cc: Ezequiel Garcia, Enric Balletbo i Serra, linux-kernel,
Gwendal Grignou, Guenter Roeck, Benson Leung, Lee Jones, kernel,
Dmitry Torokhov, Gustavo Pimentel, Randy Dunlap,
Lorenzo Pieralisi, linux-doc, Enno Luebbers, Guido Kiener,
Thomas Gleixner, Kishon Vijay Abraham I, Jonathan Corbet, Wu Hao,
Kate Stewart, Tycho Andersen, Gerd Hoffmann, Jilayne Lovejoy
In-Reply-To: <CABXOdTfU9KaBDhQcwvBGWCmVfnd02_ZFmPGtJsCtGQ-iO9A3Qw@mail.gmail.com>
On Tue, Jun 04, 2019 at 11:39:21AM -0700, Guenter Roeck wrote:
> On Tue, Jun 4, 2019 at 11:35 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Jun 04, 2019 at 01:58:38PM -0300, Ezequiel Garcia wrote:
> > > Hey Greg,
> > >
> > > > > + dev_info(&pdev->dev, "Created misc device /dev/%s\n",
> > > > > + data->misc.name);
> > > >
> > > > No need to be noisy, if all goes well, your code should be quiet.
> > > >
> > >
> > > I sometimes wonder about this being noise or not, so I will slightly
> > > hijack this thread for this discussion.
> > >
> > > >From a kernel developer point-of-view, or even from a platform
> > > developer or user with a debugging hat point-of-view, having
> > > a "device created" or "device registered" message is often very useful.
> >
> > For you, yes. For someone with 30000 devices attached to their system,
> > it is not, and causes booting to take longer than it should be.
> >
> > > In fact, I wish people would do this more often, so I don't have to
> > > deal with dynamic debug, or hack my way:
> > >
> > > diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c
> > > index 4589631798c9..473549b26bb2 100644
> > > --- a/drivers/media/i2c/ov5647.c
> > > +++ b/drivers/media/i2c/ov5647.c
> > > @@ -603,7 +603,7 @@ static int ov5647_probe(struct i2c_client *client,
> > > if (ret < 0)
> > > goto error;
> > >
> > > - dev_dbg(dev, "OmniVision OV5647 camera driver probed\n");
> > > + dev_info(dev, "OmniVision OV5647 camera driver probed\n");
> > > return 0;
> > > error:
> > > media_entity_cleanup(&sd->entity);
> > >
> > > In some subsystems, it's even a behavior I'm more or less relying on:
> > >
> > > $ git grep v4l2_info.*registered drivers/media/ | wc -l
> > > 26
> > >
> > > And on the downsides, I can't find much. It's just one little line,
> > > that is not even noticed unless you have logging turned on.
> >
> > Its better to be quiet, which is why the "default driver registration"
> > macros do not have any printk messages in them. When converting drivers
> > over to it, we made the boot process much more sane, don't try to go and
> > add messages for no good reason back in please.
> >
> > dynamic debugging can be enabled on a module and line-by-line basis,
> > even from the boot command line. So if you need debugging, you can
> > always ask someone to just reboot or unload/load the module and get the
> > message that way.
> >
>
> Can we by any chance make this an official policy ? I am kind of tired
> having to argue about this over and over again.
Sure, but how does anyone make any "official policy" in the kernel? :)
I could just go through and delete all "look ma, a new driver/device!"
messages, but that might be annoying...
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 03/10] mfd / platform: cros_ec: Miscellaneous character device to talk with the EC
From: Guenter Roeck @ 2019-06-04 18:39 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Ezequiel Garcia, Enric Balletbo i Serra, linux-kernel,
Gwendal Grignou, Guenter Roeck, Benson Leung, Lee Jones, kernel,
Dmitry Torokhov, Gustavo Pimentel, Randy Dunlap,
Lorenzo Pieralisi, linux-doc, Enno Luebbers, Guido Kiener,
Thomas Gleixner, Kishon Vijay Abraham I, Jonathan Corbet, Wu Hao,
Kate Stewart, Tycho Andersen, Gerd Hoffmann, Jilayne Lovejoy
In-Reply-To: <20190604183527.GA20098@kroah.com>
On Tue, Jun 4, 2019 at 11:35 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Tue, Jun 04, 2019 at 01:58:38PM -0300, Ezequiel Garcia wrote:
> > Hey Greg,
> >
> > > > + dev_info(&pdev->dev, "Created misc device /dev/%s\n",
> > > > + data->misc.name);
> > >
> > > No need to be noisy, if all goes well, your code should be quiet.
> > >
> >
> > I sometimes wonder about this being noise or not, so I will slightly
> > hijack this thread for this discussion.
> >
> > >From a kernel developer point-of-view, or even from a platform
> > developer or user with a debugging hat point-of-view, having
> > a "device created" or "device registered" message is often very useful.
>
> For you, yes. For someone with 30000 devices attached to their system,
> it is not, and causes booting to take longer than it should be.
>
> > In fact, I wish people would do this more often, so I don't have to
> > deal with dynamic debug, or hack my way:
> >
> > diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c
> > index 4589631798c9..473549b26bb2 100644
> > --- a/drivers/media/i2c/ov5647.c
> > +++ b/drivers/media/i2c/ov5647.c
> > @@ -603,7 +603,7 @@ static int ov5647_probe(struct i2c_client *client,
> > if (ret < 0)
> > goto error;
> >
> > - dev_dbg(dev, "OmniVision OV5647 camera driver probed\n");
> > + dev_info(dev, "OmniVision OV5647 camera driver probed\n");
> > return 0;
> > error:
> > media_entity_cleanup(&sd->entity);
> >
> > In some subsystems, it's even a behavior I'm more or less relying on:
> >
> > $ git grep v4l2_info.*registered drivers/media/ | wc -l
> > 26
> >
> > And on the downsides, I can't find much. It's just one little line,
> > that is not even noticed unless you have logging turned on.
>
> Its better to be quiet, which is why the "default driver registration"
> macros do not have any printk messages in them. When converting drivers
> over to it, we made the boot process much more sane, don't try to go and
> add messages for no good reason back in please.
>
> dynamic debugging can be enabled on a module and line-by-line basis,
> even from the boot command line. So if you need debugging, you can
> always ask someone to just reboot or unload/load the module and get the
> message that way.
>
Can we by any chance make this an official policy ? I am kind of tired
having to argue about this over and over again.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH 03/10] mfd / platform: cros_ec: Miscellaneous character device to talk with the EC
From: Greg Kroah-Hartman @ 2019-06-04 18:35 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Enric Balletbo i Serra, linux-kernel, gwendal, Guenter Roeck,
Benson Leung, Lee Jones, kernel, dtor, Gustavo Pimentel,
Randy Dunlap, Lorenzo Pieralisi, linux-doc, Enno Luebbers,
Guido Kiener, Thomas Gleixner, Kishon Vijay Abraham I,
Jonathan Corbet, Wu Hao, Kate Stewart, Tycho Andersen,
Gerd Hoffmann, Jilayne Lovejoy
In-Reply-To: <beaf3554bb85974eb118d7722ca55f1823b1850c.camel@collabora.com>
On Tue, Jun 04, 2019 at 01:58:38PM -0300, Ezequiel Garcia wrote:
> Hey Greg,
>
> > > + dev_info(&pdev->dev, "Created misc device /dev/%s\n",
> > > + data->misc.name);
> >
> > No need to be noisy, if all goes well, your code should be quiet.
> >
>
> I sometimes wonder about this being noise or not, so I will slightly
> hijack this thread for this discussion.
>
> >From a kernel developer point-of-view, or even from a platform
> developer or user with a debugging hat point-of-view, having
> a "device created" or "device registered" message is often very useful.
For you, yes. For someone with 30000 devices attached to their system,
it is not, and causes booting to take longer than it should be.
> In fact, I wish people would do this more often, so I don't have to
> deal with dynamic debug, or hack my way:
>
> diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c
> index 4589631798c9..473549b26bb2 100644
> --- a/drivers/media/i2c/ov5647.c
> +++ b/drivers/media/i2c/ov5647.c
> @@ -603,7 +603,7 @@ static int ov5647_probe(struct i2c_client *client,
> if (ret < 0)
> goto error;
>
> - dev_dbg(dev, "OmniVision OV5647 camera driver probed\n");
> + dev_info(dev, "OmniVision OV5647 camera driver probed\n");
> return 0;
> error:
> media_entity_cleanup(&sd->entity);
>
> In some subsystems, it's even a behavior I'm more or less relying on:
>
> $ git grep v4l2_info.*registered drivers/media/ | wc -l
> 26
>
> And on the downsides, I can't find much. It's just one little line,
> that is not even noticed unless you have logging turned on.
Its better to be quiet, which is why the "default driver registration"
macros do not have any printk messages in them. When converting drivers
over to it, we made the boot process much more sane, don't try to go and
add messages for no good reason back in please.
dynamic debugging can be enabled on a module and line-by-line basis,
even from the boot command line. So if you need debugging, you can
always ask someone to just reboot or unload/load the module and get the
message that way.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] Documentation/dm-init: fix multi device example
From: Helen Koike @ 2019-06-04 18:27 UTC (permalink / raw)
To: dm-devel, swboyd
Cc: wad, keescook, snitzer, linux-doc, richard.weinberger,
linux-kernel, linux-lvm, enric.balletbo, kernel, agk, Helen Koike,
Jonathan Corbet
The example in the docs regarding multiple device-mappers is invalid (it
has a wrong number of arguments), it's a left over from previous
versions of the patch.
Replace the example with an valid and tested one.
Signed-off-by: Helen Koike <helen.koike@collabora.com>
---
Documentation/device-mapper/dm-init.txt | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/device-mapper/dm-init.txt b/Documentation/device-mapper/dm-init.txt
index 8464ee7c01b8..130b3c3679c5 100644
--- a/Documentation/device-mapper/dm-init.txt
+++ b/Documentation/device-mapper/dm-init.txt
@@ -74,13 +74,13 @@ this target to /dev/mapper/lroot (depending on the rules). No uuid was assigned.
An example of multiple device-mappers, with the dm-mod.create="..." contents is shown here
split on multiple lines for readability:
- vroot,,,ro,
- 0 1740800 verity 254:0 254:0 1740800 sha1
- 76e9be054b15884a9fa85973e9cb274c93afadb6
- 5b3549d54d6c7a3837b9b81ed72e49463a64c03680c47835bef94d768e5646fe;
- vram,,,rw,
- 0 32768 linear 1:0 0,
- 32768 32768 linear 1:1 0
+ dm-linear,,1,rw,
+ 0 32768 linear 8:1 0,
+ 32768 1024000 linear 8:2 0;
+ dm-verity,,3,ro,
+ 0 1638400 verity 1 /dev/sdc1 /dev/sdc2 4096 4096 204800 1 sha256
+ ac87db56303c9c1da433d7209b5a6ef3e4779df141200cbd7c157dcb8dd89c42
+ 5ebfe87f7df3235b80a117ebc4078e44f55045487ad4a96581d1adb564615b51
Other examples (per target):
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 01/15] kbuild: remove headers_{install,check}_all
From: Sam Ravnborg @ 2019-06-04 17:57 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-kbuild, Randy Dunlap, Arnd Bergmann, David Howells,
Jani Nikula, linux-doc, linux-kernel, Jonathan Corbet,
Michal Marek
In-Reply-To: <20190604101409.2078-2-yamada.masahiro@socionext.com>
On Tue, Jun 04, 2019 at 07:13:55PM +0900, Masahiro Yamada wrote:
> headers_install_all does not make much sense any more because different
> architectures export different set of uapi/linux/ headers. As you see
> in include/uapi/linux/Kbuild, the installation of a.out.h, kvm.h, and
> kvm_para.h is arch-dependent. So, headers_install_all repeats the
> installation/removal of them.
>
> If somebody really thinks it is useful to do headers_install for all
> architectures, it would be possible by small shell-scripting, but the
> top Makefile do not have to provide entry targets just for that purpose.
Agreed, good to see this be dropped.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply
* Re: [PATCH v12] dm: add support to directly boot to a mapped device
From: Helen Koike @ 2019-06-04 17:38 UTC (permalink / raw)
To: Stephen Boyd, dm-devel
Cc: wad, keescook, snitzer, linux-doc, richard.weinberger,
linux-kernel, linux-lvm, enric.balletbo, kernel, agk
In-Reply-To: <5cf5a724.1c69fb81.1e8f0.08fb@mx.google.com>
Hi Stephen,
On 6/3/19 8:02 PM, Stephen Boyd wrote:
> Quoting Helen Koike (2019-02-21 12:33:34)
>> Add a "create" module parameter, which allows device-mapper targets to be
>> configured at boot time. This enables early use of dm targets in the boot
>> process (as the root device or otherwise) without the need of an initramfs.
>>
>> The syntax used in the boot param is based on the concise format from the
>> dmsetup tool to follow the rule of least surprise:
>>
>> sudo dmsetup table --concise /dev/mapper/lroot
>>
>> Which is:
>> dm-mod.create=<name>,<uuid>,<minor>,<flags>,<table>[,<table>+][;<name>,<uuid>,<minor>,<flags>,<table>[,<table>+]+]
>>
>> Where,
>> <name> ::= The device name.
>> <uuid> ::= xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | ""
>> <minor> ::= The device minor number | ""
>> <flags> ::= "ro" | "rw"
>> <table> ::= <start_sector> <num_sectors> <target_type> <target_args>
>> <target_type> ::= "verity" | "linear" | ...
>>
>> For example, the following could be added in the boot parameters:
>> dm-mod.create="lroot,,,rw, 0 4096 linear 98:16 0, 4096 4096 linear 98:32 0" root=/dev/dm-0
>>
>> Only the targets that were tested are allowed and the ones that doesn't
>> change any block device when the dm is create as read-only. For example,
>> mirror and cache targets are not allowed. The rationale behind this is
>> that if the user makes a mistake, choosing the wrong device to be the
>> mirror or the cache can corrupt data.
>>
>> The only targets allowed are:
>> * crypt
>> * delay
>> * linear
>> * snapshot-origin
>> * striped
>> * verity
>>
>> Co-developed-by: Will Drewry <wad@chromium.org>
>> Co-developed-by: Kees Cook <keescook@chromium.org>
>> Co-developed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>> Signed-off-by: Helen Koike <helen.koike@collabora.com>
>>
>> ---
>>
>
> I'm trying to boot a mainline linux kernel on a chromeos device with dm
> verity and a USB stick but it's not working for me even with this patch.
> I've had to hack around two problems:
>
> 1) rootwait isn't considered
>
> 2) verity doesn't seem to accept UUID for <hash_dev> or <dev>
>
> For the first problem, it happens every boot for me because I'm trying
> to boot off of a USB stick and it's behind a hub that takes a few
> seconds to enumerate. If I hack up the code to call dm_init_init() after
> the 'rootdelay' cmdline parameter is used then I can make this work. It
> would be much nicer if the whole mechanism didn't use a late initcall
> though. If it used a hook from prepare_namespace() and then looped
> waiting for devices to create when rootwait was specified it would work.
The patch was implemented with late initcall partially to be contained
in drivers/md/*, but to support rootwait, adding a hook from
prepare_namespace seems the way to go indeed.
>
> The second problem is that in chromeos we have the bootloader fill out
> the UUID of the kernel partition (%U) and then we have another parameter
> that indicates the offset from that kernel partition to add to the
> kernel partition (typically 1, i.e. PARTNROFF=1) to find the root
> filesystem partition. The way verity seems to work here is that we need
> to specify a path like /dev/sda3 or the major:minor number of the device
> on the commandline to make this work. It would be better if we could add
> in support for the PARTNROFF style that name_to_dev_t() handles so we
> can specify the root partition like we're currently doing. I suspect we
> should be able to add support for this into the device mapper layer so
> that we can specify devices this way.
hmm, I didn't test this yet but at least from what I can see in the
code, verity_ctr() calls dm_get_device() that ends up calling
name_to_dev_t() which should take care of PARTNROFF, this requires a bit
more investigation.
>
> If it helps, an example commandline I've been using to test out a usb
> stick is as follows:
>
> dm-mod.create="vroot,,0,ro, 0 4710400 verity 0 8:19 8:19 4096 4096 588800 588800 sha1 9b0a223aedbf74b06442b0f05fbff33c55edd010 414b21fba60a1901e23aec373e994942e991d6762631e54a39bc42411f244bd2"
Thanks
>
> Also, the documentation (Documentation/device-mapper/dm-init.txt) says
> we can use a way that doesn't specify so many arguments, but dm verity
> complains about not enough arguments (10) when following the example:
>
> vroot,,,ro,
> 0 1740800 verity 254:0 254:0 1740800 sha1
> 76e9be054b15884a9fa85973e9cb274c93afadb6
> 5b3549d54d6c7a3837b9b81ed72e49463a64c03680c47835bef94d768e5646fe;
>
> So the documentation needs an update?
>
Ack, I'll update this.
Thanks
Helen
^ permalink raw reply
* Re: [PATCH v2] kbuild: add support for ensuring headers are self-contained
From: Sam Ravnborg @ 2019-06-04 17:25 UTC (permalink / raw)
To: Jani Nikula
Cc: Masahiro Yamada, linux-kbuild, Randy Dunlap, Arnd Bergmann,
David Howells, Chris Wilson, Michal Marek, linux-doc,
linux-kernel, Jonathan Corbet
In-Reply-To: <20190604124248.5564-1-jani.nikula@intel.com>
On Tue, Jun 04, 2019 at 03:42:48PM +0300, Jani Nikula wrote:
> Sometimes it's useful to be able to explicitly ensure certain headers
> remain self-contained, i.e. that they are compilable as standalone
> units, by including and/or forward declaring everything they depend on.
>
> Add special target header-test-y where individual Makefiles can add
> headers to be tested if CONFIG_HEADER_TEST is enabled. This will
> generate a dummy C file per header that gets built as part of extra-y.
>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
> Cc: Michal Marek <michal.lkml@markovi.net>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Looks good, thanks.
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply
* Re: [PATCH 03/10] mfd / platform: cros_ec: Miscellaneous character device to talk with the EC
From: Ezequiel Garcia @ 2019-06-04 16:58 UTC (permalink / raw)
To: Greg Kroah-Hartman, Enric Balletbo i Serra
Cc: linux-kernel, gwendal, Guenter Roeck, Benson Leung, Lee Jones,
kernel, dtor, Gustavo Pimentel, Randy Dunlap, Lorenzo Pieralisi,
linux-doc, Enno Luebbers, Guido Kiener, Thomas Gleixner,
Kishon Vijay Abraham I, Jonathan Corbet, Wu Hao, Kate Stewart,
Tycho Andersen, Gerd Hoffmann, Jilayne Lovejoy
In-Reply-To: <20190604155228.GB9981@kroah.com>
Hey Greg,
> > + dev_info(&pdev->dev, "Created misc device /dev/%s\n",
> > + data->misc.name);
>
> No need to be noisy, if all goes well, your code should be quiet.
>
I sometimes wonder about this being noise or not, so I will slightly
hijack this thread for this discussion.
From a kernel developer point-of-view, or even from a platform
developer or user with a debugging hat point-of-view, having
a "device created" or "device registered" message is often very useful.
In fact, I wish people would do this more often, so I don't have to
deal with dynamic debug, or hack my way:
diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c
index 4589631798c9..473549b26bb2 100644
--- a/drivers/media/i2c/ov5647.c
+++ b/drivers/media/i2c/ov5647.c
@@ -603,7 +603,7 @@ static int ov5647_probe(struct i2c_client *client,
if (ret < 0)
goto error;
- dev_dbg(dev, "OmniVision OV5647 camera driver probed\n");
+ dev_info(dev, "OmniVision OV5647 camera driver probed\n");
return 0;
error:
media_entity_cleanup(&sd->entity);
In some subsystems, it's even a behavior I'm more or less relying on:
$ git grep v4l2_info.*registered drivers/media/ | wc -l
26
And on the downsides, I can't find much. It's just one little line,
that is not even noticed unless you have logging turned on.
Thanks,
Ezequiel
^ permalink raw reply related
* Re: [PATCH 03/10] mfd / platform: cros_ec: Miscellaneous character device to talk with the EC
From: Greg Kroah-Hartman @ 2019-06-04 15:52 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: linux-kernel, gwendal, Guenter Roeck, Benson Leung, Lee Jones,
kernel, dtor, Gustavo Pimentel, Randy Dunlap, Lorenzo Pieralisi,
linux-doc, Enno Luebbers, Guido Kiener, Thomas Gleixner,
Kishon Vijay Abraham I, Jonathan Corbet, Wu Hao, Kate Stewart,
Tycho Andersen, Gerd Hoffmann, Jilayne Lovejoy
In-Reply-To: <20190604152019.16100-4-enric.balletbo@collabora.com>
On Tue, Jun 04, 2019 at 05:20:12PM +0200, Enric Balletbo i Serra wrote:
> That's a driver to talk with the ChromeOS Embedded Controller via a
> miscellaneous character device, it creates an entry in /dev for every
> instance and implements basic file operations for communicating with the
> Embedded Controller with an userspace application. The API is moved to
> the uapi folder, which is supposed to contain the user space API of the
> kernel.
>
> Note that this will replace current character device interface
> implemented in the cros-ec-dev driver in the MFD subsystem. The idea is
> to move all the functionality that extends the bounds of what MFD was
> designed to platform/chrome subsystem.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
>
> Documentation/ioctl/ioctl-number.txt | 2 +-
> drivers/mfd/cros_ec_dev.c | 2 +-
> drivers/platform/chrome/Kconfig | 11 +
> drivers/platform/chrome/Makefile | 1 +
> drivers/platform/chrome/cros_ec_chardev.c | 279 ++++++++++++++++++
> .../uapi/linux/cros_ec_chardev.h | 18 +-
> 6 files changed, 302 insertions(+), 11 deletions(-)
> create mode 100644 drivers/platform/chrome/cros_ec_chardev.c
> rename drivers/mfd/cros_ec_dev.h => include/uapi/linux/cros_ec_chardev.h (70%)
>
> diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
> index c9558146ac58..8bd7907ee36d 100644
> --- a/Documentation/ioctl/ioctl-number.txt
> +++ b/Documentation/ioctl/ioctl-number.txt
> @@ -340,7 +340,7 @@ Code Seq#(hex) Include File Comments
> 0xDD 00-3F ZFCP device driver see drivers/s390/scsi/
> <mailto:aherrman@de.ibm.com>
> 0xE5 00-3F linux/fuse.h
> -0xEC 00-01 drivers/platform/chrome/cros_ec_dev.h ChromeOS EC driver
> +0xEC 00-01 include/uapi/linux/cros_ec_chardev.h ChromeOS EC driver
> 0xF3 00-3F drivers/usb/misc/sisusbvga/sisusb.h sisfb (in development)
> <mailto:thomas@winischhofer.net>
> 0xF4 00-1F video/mbxfb.h mbxfb
> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> index 607383b67cf1..11b791c28f84 100644
> --- a/drivers/mfd/cros_ec_dev.c
> +++ b/drivers/mfd/cros_ec_dev.c
> @@ -15,7 +15,7 @@
> #include <linux/slab.h>
> #include <linux/uaccess.h>
>
> -#include "cros_ec_dev.h"
> +#include <uapi/linux/cros_ec_chardev.h>
>
> #define DRV_NAME "cros-ec-dev"
>
> diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
> index 9417b982ad92..3a9ad001838a 100644
> --- a/drivers/platform/chrome/Kconfig
> +++ b/drivers/platform/chrome/Kconfig
> @@ -147,6 +147,17 @@ config CROS_KBD_LED_BACKLIGHT
> To compile this driver as a module, choose M here: the
> module will be called cros_kbd_led_backlight.
>
> +config CROS_EC_CHARDEV
> + tristate "ChromeOS EC miscdevice"
> + depends on MFD_CROS_EC_CHARDEV
> + default MFD_CROS_EC_CHARDEV
> + help
> + This driver adds file operations support to talk with the
> + ChromeOS EC from userspace via a character device.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called cros_ec_chardev.
> +
> config CROS_EC_LIGHTBAR
> tristate "Chromebook Pixel's lightbar support"
> depends on MFD_CROS_EC_CHARDEV
> diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
> index ebb57e21923b..d47a7e1097ee 100644
> --- a/drivers/platform/chrome/Makefile
> +++ b/drivers/platform/chrome/Makefile
> @@ -16,6 +16,7 @@ cros_ec_lpcs-$(CONFIG_CROS_EC_LPC_MEC) += cros_ec_lpc_mec.o
> obj-$(CONFIG_CROS_EC_LPC) += cros_ec_lpcs.o
> obj-$(CONFIG_CROS_EC_PROTO) += cros_ec_proto.o cros_ec_trace.o
> obj-$(CONFIG_CROS_KBD_LED_BACKLIGHT) += cros_kbd_led_backlight.o
> +obj-$(CONFIG_CROS_EC_CHARDEV) += cros_ec_chardev.o
> obj-$(CONFIG_CROS_EC_LIGHTBAR) += cros_ec_lightbar.o
> obj-$(CONFIG_CROS_EC_VBC) += cros_ec_vbc.o
> obj-$(CONFIG_CROS_EC_DEBUGFS) += cros_ec_debugfs.o
> diff --git a/drivers/platform/chrome/cros_ec_chardev.c b/drivers/platform/chrome/cros_ec_chardev.c
> new file mode 100644
> index 000000000000..1a0a27080026
> --- /dev/null
> +++ b/drivers/platform/chrome/cros_ec_chardev.c
> @@ -0,0 +1,279 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Miscellaneous character driver for ChromeOS Embedded Controller
> + *
> + * Copyright 2019 Google LLC
> + */
> +
> +#include <linux/init.h>
> +#include <linux/device.h>
> +#include <linux/fs.h>
> +#include <linux/list.h>
> +#include <linux/mfd/cros_ec.h>
> +#include <linux/mfd/cros_ec_commands.h>
> +#include <linux/miscdevice.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +#include <linux/types.h>
> +#include <linux/uaccess.h>
> +
> +#include <uapi/linux/cros_ec_chardev.h>
> +
> +#define DRV_NAME "cros-ec-chardev"
> +
> +static LIST_HEAD(chardev_devices);
> +static DEFINE_SPINLOCK(chardev_lock);
> +
> +struct chardev_data {
> + struct list_head list;
> + struct cros_ec_dev *ec_dev;
> + struct miscdevice misc;
> +};
> +
> +static int ec_get_version(struct cros_ec_dev *ec, char *str, int maxlen)
> +{
> + static const char * const current_image_name[] = {
> + "unknown", "read-only", "read-write", "invalid",
> + };
> + struct ec_response_get_version *resp;
> + struct cros_ec_command *msg;
> + int ret;
> +
> + msg = kzalloc(sizeof(*msg) + sizeof(*resp), GFP_KERNEL);
> + if (!msg)
> + return -ENOMEM;
> +
> + msg->command = EC_CMD_GET_VERSION + ec->cmd_offset;
> + msg->insize = sizeof(*resp);
> +
> + ret = cros_ec_cmd_xfer_status(ec->ec_dev, msg);
> + if (ret < 0) {
> + snprintf(str, maxlen,
> + "Unknown EC version, returned error: %d\n",
> + msg->result);
> + goto exit;
> + }
> +
> + resp = (struct ec_response_get_version *)msg->data;
> + if (resp->current_image >= ARRAY_SIZE(current_image_name))
> + resp->current_image = 3; /* invalid */
> +
> + snprintf(str, maxlen, "%s\n%s\n%s\n",
> + resp->version_string_ro,
> + resp->version_string_rw,
> + current_image_name[resp->current_image]);
> +
> + ret = 0;
> +exit:
> + kfree(msg);
> + return ret;
> +}
> +
> +/*
> + * Device file ops
> + */
> +static int cros_ec_chardev_open(struct inode *inode, struct file *filp)
> +{
> + struct miscdevice *mdev = filp->private_data;
> + struct cros_ec_dev *ec_dev = dev_get_drvdata(mdev->parent);
> +
> + filp->private_data = ec_dev;
> + nonseekable_open(inode, filp);
> +
> + return 0;
> +}
> +
> +static ssize_t cros_ec_chardev_read(struct file *filp, char __user *buffer,
> + size_t length, loff_t *offset)
> +{
> + char msg[sizeof(struct ec_response_get_version) +
> + sizeof(CROS_EC_DEV_VERSION)];
> + struct cros_ec_dev *ec = filp->private_data;
> + size_t count;
> + int ret;
> +
> + if (*offset != 0)
> + return 0;
> +
> + ret = ec_get_version(ec, msg, sizeof(msg));
> + if (ret)
> + return ret;
> +
> + count = min(length, strlen(msg));
> +
> + if (copy_to_user(buffer, msg, count))
> + return -EFAULT;
> +
> + *offset = count;
> + return count;
> +}
> +
> +/*
> + * Ioctls
> + */
> +static long cros_ec_chardev_ioctl_xcmd(struct cros_ec_dev *ec, void __user *arg)
> +{
> + struct cros_ec_command *s_cmd;
> + struct cros_ec_command u_cmd;
> + long ret;
> +
> + if (copy_from_user(&u_cmd, arg, sizeof(u_cmd)))
> + return -EFAULT;
> +
> + if (u_cmd.outsize > EC_MAX_MSG_BYTES ||
> + u_cmd.insize > EC_MAX_MSG_BYTES)
> + return -EINVAL;
> +
> + s_cmd = kmalloc(sizeof(*s_cmd) + max(u_cmd.outsize, u_cmd.insize),
> + GFP_KERNEL);
> + if (!s_cmd)
> + return -ENOMEM;
> +
> + if (copy_from_user(s_cmd, arg, sizeof(*s_cmd) + u_cmd.outsize)) {
> + ret = -EFAULT;
> + goto exit;
> + }
> +
> + if (u_cmd.outsize != s_cmd->outsize ||
> + u_cmd.insize != s_cmd->insize) {
> + ret = -EINVAL;
> + goto exit;
> + }
> +
> + s_cmd->command += ec->cmd_offset;
> + ret = cros_ec_cmd_xfer(ec->ec_dev, s_cmd);
> + /* Only copy data to userland if data was received. */
> + if (ret < 0)
> + goto exit;
> +
> + if (copy_to_user(arg, s_cmd, sizeof(*s_cmd) + s_cmd->insize))
> + ret = -EFAULT;
> +exit:
> + kfree(s_cmd);
> + return ret;
> +}
> +
> +static long cros_ec_chardev_ioctl_readmem(struct cros_ec_dev *ec,
> + void __user *arg)
> +{
> + struct cros_ec_device *ec_dev = ec->ec_dev;
> + struct cros_ec_readmem s_mem = { };
> + long num;
> +
> + /* Not every platform supports direct reads */
> + if (!ec_dev->cmd_readmem)
> + return -ENOTTY;
> +
> + if (copy_from_user(&s_mem, arg, sizeof(s_mem)))
> + return -EFAULT;
> +
> + num = ec_dev->cmd_readmem(ec_dev, s_mem.offset, s_mem.bytes,
> + s_mem.buffer);
> + if (num <= 0)
> + return num;
> +
> + if (copy_to_user((void __user *)arg, &s_mem, sizeof(s_mem)))
> + return -EFAULT;
> +
> + return num;
> +}
> +
> +static long cros_ec_chardev_ioctl(struct file *filp, unsigned int cmd,
> + unsigned long arg)
> +{
> + struct cros_ec_dev *ec = filp->private_data;
> +
> + if (_IOC_TYPE(cmd) != CROS_EC_DEV_IOC)
> + return -ENOTTY;
> +
> + switch (cmd) {
> + case CROS_EC_DEV_IOCXCMD:
> + return cros_ec_chardev_ioctl_xcmd(ec, (void __user *)arg);
> + case CROS_EC_DEV_IOCRDMEM:
> + return cros_ec_chardev_ioctl_readmem(ec, (void __user *)arg);
> + }
> +
> + return -ENOTTY;
> +}
> +
> +static const struct file_operations chardev_fops = {
> + .open = cros_ec_chardev_open,
> + .read = cros_ec_chardev_read,
> + .unlocked_ioctl = cros_ec_chardev_ioctl,
> +#ifdef CONFIG_COMPAT
> + .compat_ioctl = cros_ec_chardev_ioctl,
> +#endif
> +};
> +
> +static int cros_ec_chardev_probe(struct platform_device *pdev)
> +{
> + struct cros_ec_dev *ec_dev = dev_get_drvdata(pdev->dev.parent);
> + struct cros_ec_platform *ec_platform = dev_get_platdata(ec_dev->dev);
> + struct chardev_data *data;
> + int ret;
> +
> + /* Create a char device: we want to create it anew */
> + data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + data->ec_dev = ec_dev;
> + data->misc.minor = MISC_DYNAMIC_MINOR;
> + data->misc.fops = &chardev_fops;
> + data->misc.name = ec_platform->ec_name;
> + data->misc.parent = pdev->dev.parent;
> +
> + ret = misc_register(&data->misc);
> + if (ret)
> + return ret;
> +
> + spin_lock(&chardev_lock);
> + list_add(&data->list, &chardev_devices);
> + spin_unlock(&chardev_lock);
> +
> + dev_info(&pdev->dev, "Created misc device /dev/%s\n",
> + data->misc.name);
No need to be noisy, if all goes well, your code should be quiet.
> +
> + return 0;
> +}
> +
> +static int cros_ec_chardev_remove(struct platform_device *pdev)
> +{
> + struct cros_ec_dev *ec_dev = dev_get_drvdata(pdev->dev.parent);
> + struct chardev_data *data;
> +
> + list_for_each_entry(data, &chardev_devices, list)
> + if (data->ec_dev == ec_dev)
> + break;
> +
> + if (data->ec_dev != ec_dev) {
> + dev_err(&pdev->dev,
> + "remove called but miscdevice %s not found\n",
> + data->misc.name);
> + return -ENODEV;
> + }
Why do you have this separate list of devices? You don't seem to need
it, you only iterate over it, why is it needed?
> + spin_lock(&chardev_lock);
> + list_del(&data->list);
> + spin_unlock(&chardev_lock);
> + misc_deregister(&data->misc);
> +
> + return 0;
> +}
You also iterate over the list without the lock, so why even have the
lock? Are you sure the list, and the lock, is even needed?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 13/22] docs: soundwire: locking: fix tags for a code-block
From: Vinod Koul @ 2019-06-04 15:19 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Sanyog Kale, Pierre-Louis Bossart, alsa-devel
In-Reply-To: <0ea9c284f8db3867985c410d2764a2b68e5b35c1.1559656538.git.mchehab+samsung@kernel.org>
On 04-06-19, 11:17, Mauro Carvalho Chehab wrote:
> There's an ascii artwork at Example 1 whose code-block is not properly
> idented, causing those warnings.
>
> Documentation/driver-api/soundwire/locking.rst:50: WARNING: Inconsistent literal block quoting.
> Documentation/driver-api/soundwire/locking.rst:51: WARNING: Line block ends without a blank line.
> Documentation/driver-api/soundwire/locking.rst:55: WARNING: Inline substitution_reference start-string without end-string.
> Documentation/driver-api/soundwire/locking.rst:56: WARNING: Line block ends without a blank line.
Applied, thanks
--
~Vinod
^ permalink raw reply
* [PATCH 03/10] mfd / platform: cros_ec: Miscellaneous character device to talk with the EC
From: Enric Balletbo i Serra @ 2019-06-04 15:20 UTC (permalink / raw)
To: linux-kernel
Cc: gwendal, Guenter Roeck, Benson Leung, Lee Jones, kernel, dtor,
Gustavo Pimentel, Randy Dunlap, Lorenzo Pieralisi, linux-doc,
Enno Luebbers, Guido Kiener, Thomas Gleixner,
Kishon Vijay Abraham I, Jonathan Corbet, Wu Hao, Kate Stewart,
Greg Kroah-Hartman, Tycho Andersen, Gerd Hoffmann,
Jilayne Lovejoy
In-Reply-To: <20190604152019.16100-1-enric.balletbo@collabora.com>
That's a driver to talk with the ChromeOS Embedded Controller via a
miscellaneous character device, it creates an entry in /dev for every
instance and implements basic file operations for communicating with the
Embedded Controller with an userspace application. The API is moved to
the uapi folder, which is supposed to contain the user space API of the
kernel.
Note that this will replace current character device interface
implemented in the cros-ec-dev driver in the MFD subsystem. The idea is
to move all the functionality that extends the bounds of what MFD was
designed to platform/chrome subsystem.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
Documentation/ioctl/ioctl-number.txt | 2 +-
drivers/mfd/cros_ec_dev.c | 2 +-
drivers/platform/chrome/Kconfig | 11 +
drivers/platform/chrome/Makefile | 1 +
drivers/platform/chrome/cros_ec_chardev.c | 279 ++++++++++++++++++
.../uapi/linux/cros_ec_chardev.h | 18 +-
6 files changed, 302 insertions(+), 11 deletions(-)
create mode 100644 drivers/platform/chrome/cros_ec_chardev.c
rename drivers/mfd/cros_ec_dev.h => include/uapi/linux/cros_ec_chardev.h (70%)
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index c9558146ac58..8bd7907ee36d 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -340,7 +340,7 @@ Code Seq#(hex) Include File Comments
0xDD 00-3F ZFCP device driver see drivers/s390/scsi/
<mailto:aherrman@de.ibm.com>
0xE5 00-3F linux/fuse.h
-0xEC 00-01 drivers/platform/chrome/cros_ec_dev.h ChromeOS EC driver
+0xEC 00-01 include/uapi/linux/cros_ec_chardev.h ChromeOS EC driver
0xF3 00-3F drivers/usb/misc/sisusbvga/sisusb.h sisfb (in development)
<mailto:thomas@winischhofer.net>
0xF4 00-1F video/mbxfb.h mbxfb
diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index 607383b67cf1..11b791c28f84 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -15,7 +15,7 @@
#include <linux/slab.h>
#include <linux/uaccess.h>
-#include "cros_ec_dev.h"
+#include <uapi/linux/cros_ec_chardev.h>
#define DRV_NAME "cros-ec-dev"
diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
index 9417b982ad92..3a9ad001838a 100644
--- a/drivers/platform/chrome/Kconfig
+++ b/drivers/platform/chrome/Kconfig
@@ -147,6 +147,17 @@ config CROS_KBD_LED_BACKLIGHT
To compile this driver as a module, choose M here: the
module will be called cros_kbd_led_backlight.
+config CROS_EC_CHARDEV
+ tristate "ChromeOS EC miscdevice"
+ depends on MFD_CROS_EC_CHARDEV
+ default MFD_CROS_EC_CHARDEV
+ help
+ This driver adds file operations support to talk with the
+ ChromeOS EC from userspace via a character device.
+
+ To compile this driver as a module, choose M here: the
+ module will be called cros_ec_chardev.
+
config CROS_EC_LIGHTBAR
tristate "Chromebook Pixel's lightbar support"
depends on MFD_CROS_EC_CHARDEV
diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
index ebb57e21923b..d47a7e1097ee 100644
--- a/drivers/platform/chrome/Makefile
+++ b/drivers/platform/chrome/Makefile
@@ -16,6 +16,7 @@ cros_ec_lpcs-$(CONFIG_CROS_EC_LPC_MEC) += cros_ec_lpc_mec.o
obj-$(CONFIG_CROS_EC_LPC) += cros_ec_lpcs.o
obj-$(CONFIG_CROS_EC_PROTO) += cros_ec_proto.o cros_ec_trace.o
obj-$(CONFIG_CROS_KBD_LED_BACKLIGHT) += cros_kbd_led_backlight.o
+obj-$(CONFIG_CROS_EC_CHARDEV) += cros_ec_chardev.o
obj-$(CONFIG_CROS_EC_LIGHTBAR) += cros_ec_lightbar.o
obj-$(CONFIG_CROS_EC_VBC) += cros_ec_vbc.o
obj-$(CONFIG_CROS_EC_DEBUGFS) += cros_ec_debugfs.o
diff --git a/drivers/platform/chrome/cros_ec_chardev.c b/drivers/platform/chrome/cros_ec_chardev.c
new file mode 100644
index 000000000000..1a0a27080026
--- /dev/null
+++ b/drivers/platform/chrome/cros_ec_chardev.c
@@ -0,0 +1,279 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Miscellaneous character driver for ChromeOS Embedded Controller
+ *
+ * Copyright 2019 Google LLC
+ */
+
+#include <linux/init.h>
+#include <linux/device.h>
+#include <linux/fs.h>
+#include <linux/list.h>
+#include <linux/mfd/cros_ec.h>
+#include <linux/mfd/cros_ec_commands.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+#include <linux/uaccess.h>
+
+#include <uapi/linux/cros_ec_chardev.h>
+
+#define DRV_NAME "cros-ec-chardev"
+
+static LIST_HEAD(chardev_devices);
+static DEFINE_SPINLOCK(chardev_lock);
+
+struct chardev_data {
+ struct list_head list;
+ struct cros_ec_dev *ec_dev;
+ struct miscdevice misc;
+};
+
+static int ec_get_version(struct cros_ec_dev *ec, char *str, int maxlen)
+{
+ static const char * const current_image_name[] = {
+ "unknown", "read-only", "read-write", "invalid",
+ };
+ struct ec_response_get_version *resp;
+ struct cros_ec_command *msg;
+ int ret;
+
+ msg = kzalloc(sizeof(*msg) + sizeof(*resp), GFP_KERNEL);
+ if (!msg)
+ return -ENOMEM;
+
+ msg->command = EC_CMD_GET_VERSION + ec->cmd_offset;
+ msg->insize = sizeof(*resp);
+
+ ret = cros_ec_cmd_xfer_status(ec->ec_dev, msg);
+ if (ret < 0) {
+ snprintf(str, maxlen,
+ "Unknown EC version, returned error: %d\n",
+ msg->result);
+ goto exit;
+ }
+
+ resp = (struct ec_response_get_version *)msg->data;
+ if (resp->current_image >= ARRAY_SIZE(current_image_name))
+ resp->current_image = 3; /* invalid */
+
+ snprintf(str, maxlen, "%s\n%s\n%s\n",
+ resp->version_string_ro,
+ resp->version_string_rw,
+ current_image_name[resp->current_image]);
+
+ ret = 0;
+exit:
+ kfree(msg);
+ return ret;
+}
+
+/*
+ * Device file ops
+ */
+static int cros_ec_chardev_open(struct inode *inode, struct file *filp)
+{
+ struct miscdevice *mdev = filp->private_data;
+ struct cros_ec_dev *ec_dev = dev_get_drvdata(mdev->parent);
+
+ filp->private_data = ec_dev;
+ nonseekable_open(inode, filp);
+
+ return 0;
+}
+
+static ssize_t cros_ec_chardev_read(struct file *filp, char __user *buffer,
+ size_t length, loff_t *offset)
+{
+ char msg[sizeof(struct ec_response_get_version) +
+ sizeof(CROS_EC_DEV_VERSION)];
+ struct cros_ec_dev *ec = filp->private_data;
+ size_t count;
+ int ret;
+
+ if (*offset != 0)
+ return 0;
+
+ ret = ec_get_version(ec, msg, sizeof(msg));
+ if (ret)
+ return ret;
+
+ count = min(length, strlen(msg));
+
+ if (copy_to_user(buffer, msg, count))
+ return -EFAULT;
+
+ *offset = count;
+ return count;
+}
+
+/*
+ * Ioctls
+ */
+static long cros_ec_chardev_ioctl_xcmd(struct cros_ec_dev *ec, void __user *arg)
+{
+ struct cros_ec_command *s_cmd;
+ struct cros_ec_command u_cmd;
+ long ret;
+
+ if (copy_from_user(&u_cmd, arg, sizeof(u_cmd)))
+ return -EFAULT;
+
+ if (u_cmd.outsize > EC_MAX_MSG_BYTES ||
+ u_cmd.insize > EC_MAX_MSG_BYTES)
+ return -EINVAL;
+
+ s_cmd = kmalloc(sizeof(*s_cmd) + max(u_cmd.outsize, u_cmd.insize),
+ GFP_KERNEL);
+ if (!s_cmd)
+ return -ENOMEM;
+
+ if (copy_from_user(s_cmd, arg, sizeof(*s_cmd) + u_cmd.outsize)) {
+ ret = -EFAULT;
+ goto exit;
+ }
+
+ if (u_cmd.outsize != s_cmd->outsize ||
+ u_cmd.insize != s_cmd->insize) {
+ ret = -EINVAL;
+ goto exit;
+ }
+
+ s_cmd->command += ec->cmd_offset;
+ ret = cros_ec_cmd_xfer(ec->ec_dev, s_cmd);
+ /* Only copy data to userland if data was received. */
+ if (ret < 0)
+ goto exit;
+
+ if (copy_to_user(arg, s_cmd, sizeof(*s_cmd) + s_cmd->insize))
+ ret = -EFAULT;
+exit:
+ kfree(s_cmd);
+ return ret;
+}
+
+static long cros_ec_chardev_ioctl_readmem(struct cros_ec_dev *ec,
+ void __user *arg)
+{
+ struct cros_ec_device *ec_dev = ec->ec_dev;
+ struct cros_ec_readmem s_mem = { };
+ long num;
+
+ /* Not every platform supports direct reads */
+ if (!ec_dev->cmd_readmem)
+ return -ENOTTY;
+
+ if (copy_from_user(&s_mem, arg, sizeof(s_mem)))
+ return -EFAULT;
+
+ num = ec_dev->cmd_readmem(ec_dev, s_mem.offset, s_mem.bytes,
+ s_mem.buffer);
+ if (num <= 0)
+ return num;
+
+ if (copy_to_user((void __user *)arg, &s_mem, sizeof(s_mem)))
+ return -EFAULT;
+
+ return num;
+}
+
+static long cros_ec_chardev_ioctl(struct file *filp, unsigned int cmd,
+ unsigned long arg)
+{
+ struct cros_ec_dev *ec = filp->private_data;
+
+ if (_IOC_TYPE(cmd) != CROS_EC_DEV_IOC)
+ return -ENOTTY;
+
+ switch (cmd) {
+ case CROS_EC_DEV_IOCXCMD:
+ return cros_ec_chardev_ioctl_xcmd(ec, (void __user *)arg);
+ case CROS_EC_DEV_IOCRDMEM:
+ return cros_ec_chardev_ioctl_readmem(ec, (void __user *)arg);
+ }
+
+ return -ENOTTY;
+}
+
+static const struct file_operations chardev_fops = {
+ .open = cros_ec_chardev_open,
+ .read = cros_ec_chardev_read,
+ .unlocked_ioctl = cros_ec_chardev_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = cros_ec_chardev_ioctl,
+#endif
+};
+
+static int cros_ec_chardev_probe(struct platform_device *pdev)
+{
+ struct cros_ec_dev *ec_dev = dev_get_drvdata(pdev->dev.parent);
+ struct cros_ec_platform *ec_platform = dev_get_platdata(ec_dev->dev);
+ struct chardev_data *data;
+ int ret;
+
+ /* Create a char device: we want to create it anew */
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->ec_dev = ec_dev;
+ data->misc.minor = MISC_DYNAMIC_MINOR;
+ data->misc.fops = &chardev_fops;
+ data->misc.name = ec_platform->ec_name;
+ data->misc.parent = pdev->dev.parent;
+
+ ret = misc_register(&data->misc);
+ if (ret)
+ return ret;
+
+ spin_lock(&chardev_lock);
+ list_add(&data->list, &chardev_devices);
+ spin_unlock(&chardev_lock);
+
+ dev_info(&pdev->dev, "Created misc device /dev/%s\n",
+ data->misc.name);
+
+ return 0;
+}
+
+static int cros_ec_chardev_remove(struct platform_device *pdev)
+{
+ struct cros_ec_dev *ec_dev = dev_get_drvdata(pdev->dev.parent);
+ struct chardev_data *data;
+
+ list_for_each_entry(data, &chardev_devices, list)
+ if (data->ec_dev == ec_dev)
+ break;
+
+ if (data->ec_dev != ec_dev) {
+ dev_err(&pdev->dev,
+ "remove called but miscdevice %s not found\n",
+ data->misc.name);
+ return -ENODEV;
+ }
+
+ spin_lock(&chardev_lock);
+ list_del(&data->list);
+ spin_unlock(&chardev_lock);
+ misc_deregister(&data->misc);
+
+ return 0;
+}
+
+static struct platform_driver cros_ec_chardev_driver = {
+ .driver = {
+ .name = DRV_NAME,
+ },
+ .probe = cros_ec_chardev_probe,
+ .remove = cros_ec_chardev_remove,
+};
+
+module_platform_driver(cros_ec_chardev_driver);
+
+MODULE_ALIAS("platform:" DRV_NAME);
+MODULE_AUTHOR("Enric Balletbo i Serra <enric.balletbo@collabora.com>");
+MODULE_DESCRIPTION("ChromeOS EC Miscellaneous Character Driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/mfd/cros_ec_dev.h b/include/uapi/linux/cros_ec_chardev.h
similarity index 70%
rename from drivers/mfd/cros_ec_dev.h
rename to include/uapi/linux/cros_ec_chardev.h
index 7a42c3ef50e4..c6dd2549a2a5 100644
--- a/drivers/mfd/cros_ec_dev.h
+++ b/include/uapi/linux/cros_ec_chardev.h
@@ -1,12 +1,12 @@
-/* SPDX-License-Identifier: GPL-2.0-or-later */
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
/*
- * cros_ec_dev - expose the Chrome OS Embedded Controller to userspace
+ * ChromeOS EC device interface.
*
* Copyright (C) 2014 Google, Inc.
*/
-#ifndef _CROS_EC_DEV_H_
-#define _CROS_EC_DEV_H_
+#ifndef _UAPI_LINUX_CROS_EC_DEV_H_
+#define _UAPI_LINUX_CROS_EC_DEV_H_
#include <linux/ioctl.h>
#include <linux/types.h>
@@ -20,16 +20,16 @@
* @bytes: Number of bytes to read. Zero means "read a string" (including '\0')
* At most only EC_MEMMAP_SIZE bytes can be read.
* @buffer: Where to store the result. The ioctl returns the number of bytes
- * read or negative on error.
+ * read or negative on error.
*/
struct cros_ec_readmem {
- uint32_t offset;
- uint32_t bytes;
- uint8_t buffer[EC_MEMMAP_SIZE];
+ __u32 offset;
+ __u32 bytes;
+ __u8 buffer[EC_MEMMAP_SIZE];
};
#define CROS_EC_DEV_IOC 0xEC
#define CROS_EC_DEV_IOCXCMD _IOWR(CROS_EC_DEV_IOC, 0, struct cros_ec_command)
#define CROS_EC_DEV_IOCRDMEM _IOWR(CROS_EC_DEV_IOC, 1, struct cros_ec_readmem)
-#endif /* _CROS_EC_DEV_H_ */
+#endif /* _UAPI_LINUX_CROS_EC_DEV_H_ */
--
2.20.1
^ permalink raw reply related
* Re: [kbuild:kunit 14/17] htmldocs: include/kunit/kunit-stream.h:58: warning: Function parameter or member '2' not described in '__printf'
From: Brendan Higgins @ 2019-06-04 15:15 UTC (permalink / raw)
To: Randy Dunlap
Cc: kbuild test robot, kbuild-all, linux-kbuild, Masahiro Yamada,
Felix Guo, linux-doc@vger.kernel.org, Jonathan Corbet
In-Reply-To: <94e6e17c-e360-f56d-674c-84cc0032ca4a@infradead.org>
On Mon, May 20, 2019 at 9:49 PM Randy Dunlap <rdunlap@infradead.org> wrote:
>
> On 5/10/19 2:03 PM, Brendan Higgins wrote:
> > On Thu, May 9, 2019 at 6:23 PM kbuild test robot <lkp@intel.com> wrote:
> >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git kunit
> >> head: c505c0b2e6237c729634327c178f5b0094f1c958
> >> commit: c69e87665049970d1c2d6fe2fa1ae7a7c8655420 [14/17] Documentation: kunit: add documentation for KUnit
> >> reproduce: make htmldocs
> >>
> >> If you fix the issue, kindly add following tag
> >> Reported-by: kbuild test robot <lkp@intel.com>
> >>
> >> All warnings (new ones prefixed by >>):
> > < snip >
> >> drivers/gpu/drm/i915/i915_vma.h:50: warning: cannot understand function prototype: 'struct i915_vma '
> >> drivers/gpu/drm/i915/i915_vma.h:1: warning: no structured comments found
> >> drivers/gpu/drm/i915/intel_guc_fwif.h:536: warning: cannot understand function prototype: 'struct guc_log_buffer_state '
> >> drivers/gpu/drm/i915/i915_trace.h:1: warning: no structured comments found
> >> drivers/gpu/drm/i915/i915_reg.h:156: warning: bad line:
> >> include/linux/interconnect.h:1: warning: no structured comments found
> >>>> include/kunit/kunit-stream.h:58: warning: Function parameter or member '2' not described in '__printf'
> >
> > This looks like a bug in the kernel-doc parser: __printf in this context is:
> >
> >> 8dcda743 Brendan Higgins 2019-05-01 56 void __printf(2, 3) kunit_stream_add(struct kunit_stream *this,
> >> 8dcda743 Brendan Higgins 2019-05-01 57 const char *fmt, ...);
> >
> > which is an attribute to tell the compiler that this is a printf style
> > function with a printf style format string; it doesn't make sense to
> > describe it's parameters.
>
> Yes. I'm a little surprised that this has never come up before, but in my
> quick examination, it seems that most people put the __printf() attribute
> in a header file but not in the .c implementation file, then they document
> the function in the .c file, not in the header file, so it hasn't been needed.
>
> Ignoring __printf() could be added to scripts/kernel-doc. I added
> kernel-doc notation to <linux/kernel.h> panic() and then tested it with
> the patch below. ItWorksForMe. :)
>
>
> >> include/kunit/kunit-stream.h:58: warning: Function parameter or member '3' not described in '__printf'
> >> include/kunit/kunit-stream.h:58: warning: Excess function parameter 'this' description in '__printf'
> >> include/kunit/kunit-stream.h:58: warning: Excess function parameter 'fmt' description in '__printf'
> >> include/linux/skbuff.h:897: warning: Function parameter or member 'dev_scratch' not described in 'sk_buff'
> > < snip >
> >> fs/debugfs/file.c:439: WARNING: Inline literal start-string without end-string.
> >>
> >> vim +58 include/kunit/kunit-stream.h
> >>
> >> 8dcda743 Brendan Higgins 2019-05-01 48
> >> 8dcda743 Brendan Higgins 2019-05-01 49 /**
> >> 8dcda743 Brendan Higgins 2019-05-01 50 * kunit_stream_add(): adds the formatted input to the internal buffer.
> >> 8dcda743 Brendan Higgins 2019-05-01 51 * @this: the stream being operated on.
> >> 8dcda743 Brendan Higgins 2019-05-01 52 * @fmt: printf style format string to append to stream.
> >> 8dcda743 Brendan Higgins 2019-05-01 53 *
> >> 8dcda743 Brendan Higgins 2019-05-01 54 * Appends the formatted string, @fmt, to the internal buffer.
> >> 8dcda743 Brendan Higgins 2019-05-01 55 */
> >> 8dcda743 Brendan Higgins 2019-05-01 56 void __printf(2, 3) kunit_stream_add(struct kunit_stream *this,
> >> 8dcda743 Brendan Higgins 2019-05-01 57 const char *fmt, ...);
> >> 8dcda743 Brendan Higgins 2019-05-01 @58
> >>
> >> :::::: The code at line 58 was first introduced by commit
> >> :::::: 8dcda743c31c1ffc0ac13f3d23f3dd1b85b545f8 kunit: test: add kunit_stream a std::stream like logger
> >
> > Thanks!
>
>
> ---
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Ignore __printf() function attributes just as other __attribute__
> strings are ignored.
>
> Fixes this kernel-doc warning message:
> include/kunit/kunit-stream.h:58: warning: Function parameter or member '2' not described in '__printf'
>
> Reported-by: kbuild test robot <lkp@intel.com>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Brendan Higgins <brendanhiggins@google.com>
> ---
Thanks! I just tried out your patch and it looks like it works.
Tested-by: Brendan Higgins <brendanhiggins@google.com>
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 13/22] docs: soundwire: locking: fix tags for a code-block
From: Pierre-Louis Bossart @ 2019-06-04 15:12 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List
Cc: alsa-devel, Jonathan Corbet, linux-kernel, Mauro Carvalho Chehab,
Vinod Koul, Sanyog Kale
In-Reply-To: <0ea9c284f8db3867985c410d2764a2b68e5b35c1.1559656538.git.mchehab+samsung@kernel.org>
On 6/4/19 9:17 AM, Mauro Carvalho Chehab wrote:
> There's an ascii artwork at Example 1 whose code-block is not properly
> idented, causing those warnings.
>
> Documentation/driver-api/soundwire/locking.rst:50: WARNING: Inconsistent literal block quoting.
> Documentation/driver-api/soundwire/locking.rst:51: WARNING: Line block ends without a blank line.
> Documentation/driver-api/soundwire/locking.rst:55: WARNING: Inline substitution_reference start-string without end-string.
> Documentation/driver-api/soundwire/locking.rst:56: WARNING: Line block ends without a blank line.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Thanks for fixing this.
> ---
> Documentation/driver-api/soundwire/locking.rst | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/driver-api/soundwire/locking.rst b/Documentation/driver-api/soundwire/locking.rst
> index 253f73555255..3a7ffb3d87f3 100644
> --- a/Documentation/driver-api/soundwire/locking.rst
> +++ b/Documentation/driver-api/soundwire/locking.rst
> @@ -44,7 +44,9 @@ Message transfer.
> b. Transfer message (Read/Write) to Slave1 or broadcast message on
> Bus in case of bank switch.
>
> - c. Release Message lock ::
> + c. Release Message lock
> +
> + ::
>
> +----------+ +---------+
> | | | |
>
^ permalink raw reply
* [PATCH v2 15/22] docs: security: core.rst: Fix several warnings
From: Mauro Carvalho Chehab @ 2019-06-04 14:17 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, David Howells, keyrings
In-Reply-To: <cover.1559656538.git.mchehab+samsung@kernel.org>
Multi-line literal markups only work when they're idented at the
same level, with is not the case here:
Documentation/security/keys/core.rst:1597: WARNING: Inline literal start-string without end-string.
Documentation/security/keys/core.rst:1597: WARNING: Inline emphasis start-string without end-string.
Documentation/security/keys/core.rst:1597: WARNING: Inline emphasis start-string without end-string.
Documentation/security/keys/core.rst:1598: WARNING: Inline emphasis start-string without end-string.
Documentation/security/keys/core.rst:1598: WARNING: Inline emphasis start-string without end-string.
Documentation/security/keys/core.rst:1600: WARNING: Inline literal start-string without end-string.
Documentation/security/keys/core.rst:1600: WARNING: Inline emphasis start-string without end-string.
Documentation/security/keys/core.rst:1600: WARNING: Inline emphasis start-string without end-string.
Documentation/security/keys/core.rst:1600: WARNING: Inline emphasis start-string without end-string.
Documentation/security/keys/core.rst:1600: WARNING: Inline emphasis start-string without end-string.
Documentation/security/keys/core.rst:1666: WARNING: Inline literal start-string without end-string.
Documentation/security/keys/core.rst:1666: WARNING: Inline emphasis start-string without end-string.
Documentation/security/keys/core.rst:1666: WARNING: Inline emphasis start-string without end-string.
Documentation/security/keys/core.rst:1666: WARNING: Inline emphasis start-string without end-string.
Fix it by using a code-block instead.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/security/keys/core.rst | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/Documentation/security/keys/core.rst b/Documentation/security/keys/core.rst
index 9521c4207f01..3fd60dcb2dc6 100644
--- a/Documentation/security/keys/core.rst
+++ b/Documentation/security/keys/core.rst
@@ -1594,10 +1594,12 @@ The structure has a number of fields, some of which are mandatory:
attempted key link operation. If there is no match, -EINVAL is returned.
- * ``int (*asym_eds_op)(struct kernel_pkey_params *params,
- const void *in, void *out);``
- ``int (*asym_verify_signature)(struct kernel_pkey_params *params,
- const void *in, const void *in2);``
+ * ``asym_eds_op`` and ``asym_verify_signature``::
+
+ int (*asym_eds_op)(struct kernel_pkey_params *params,
+ const void *in, void *out);
+ int (*asym_verify_signature)(struct kernel_pkey_params *params,
+ const void *in, const void *in2);
These methods are optional. If provided the first allows a key to be
used to encrypt, decrypt or sign a blob of data, and the second allows a
@@ -1662,8 +1664,10 @@ The structure has a number of fields, some of which are mandatory:
required crypto isn't available.
- * ``int (*asym_query)(const struct kernel_pkey_params *params,
- struct kernel_pkey_query *info);``
+ * ``asym_query``::
+
+ int (*asym_query)(const struct kernel_pkey_params *params,
+ struct kernel_pkey_query *info);
This method is optional. If provided it allows information about the
public or asymmetric key held in the key to be determined.
--
2.21.0
^ permalink raw reply related
* [PATCH v2 22/22] docs: Kbuild/Makefile: allow check for missing docs at build time
From: Mauro Carvalho Chehab @ 2019-06-04 14:17 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Masahiro Yamada, Randy Dunlap
In-Reply-To: <cover.1559656538.git.mchehab+samsung@kernel.org>
While this doesn't make sense for production Kernels, in order to
avoid regressions when new documents are added, let's add a
check target at the make file.
For now, the only check it does is to verify if there isn't
any documents with a broken link.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/Kconfig | 13 +++++++++++++
Documentation/Makefile | 5 +++++
Kconfig | 2 ++
scripts/documentation-file-ref-check | 9 +++++++++
4 files changed, 29 insertions(+)
create mode 100644 Documentation/Kconfig
diff --git a/Documentation/Kconfig b/Documentation/Kconfig
new file mode 100644
index 000000000000..66046fa1c341
--- /dev/null
+++ b/Documentation/Kconfig
@@ -0,0 +1,13 @@
+config WARN_MISSING_DOCUMENTS
+
+ bool "Warn if there's a missing documentation file"
+ depends on COMPILE_TEST
+ help
+ It is not uncommon that a document gets renamed.
+ This option makes the Kernel to check for missing dependencies,
+ warning when something is missing. Works only if the Kernel
+ is built from a git tree.
+
+ If unsure, select 'N'.
+
+
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 2edd03b1dad6..89857285a024 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -4,6 +4,11 @@
subdir-y := devicetree/bindings/
+# Check for broken documentation file references
+ifeq ($(CONFIG_WARN_MISSING_DOCUMENTS),y)
+$(shell $(srctree)/scripts/documentation-file-ref-check --warn)
+endif
+
# You can set these variables from the command line.
SPHINXBUILD = sphinx-build
SPHINXOPTS =
diff --git a/Kconfig b/Kconfig
index 48a80beab685..990b0c390dfc 100644
--- a/Kconfig
+++ b/Kconfig
@@ -30,3 +30,5 @@ source "crypto/Kconfig"
source "lib/Kconfig"
source "lib/Kconfig.debug"
+
+source "Documentation/Kconfig"
diff --git a/scripts/documentation-file-ref-check b/scripts/documentation-file-ref-check
index ff16db269079..440227bb55a9 100755
--- a/scripts/documentation-file-ref-check
+++ b/scripts/documentation-file-ref-check
@@ -22,9 +22,16 @@ $scriptname =~ s,.*/([^/]+/),$1,;
# Parse arguments
my $help = 0;
my $fix = 0;
+my $warn = 0;
+
+if (! -d ".git") {
+ printf "Warning: can't check if file exists, as this is not a git tree";
+ exit 0;
+}
GetOptions(
'fix' => \$fix,
+ 'warn' => \$warn,
'h|help|usage' => \$help,
);
@@ -139,6 +146,8 @@ while (<IN>) {
if (!($ref =~ m/(scripts|Kconfig|Kbuild)/)) {
$broken_ref{$ref}++;
}
+ } elsif ($warn) {
+ print STDERR "Warning: $f references a file that doesn't exist: $fulref\n";
} else {
print STDERR "$f: $fulref\n";
}
--
2.21.0
^ permalink raw reply related
* [PATCH v2 02/22] isdn: mISDN: remove a bogus reference to a non-existing doc
From: Mauro Carvalho Chehab @ 2019-06-04 14:17 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Karsten Keil, netdev
In-Reply-To: <cover.1559656538.git.mchehab+samsung@kernel.org>
The mISDN driver was added on those commits:
960366cf8dbb ("Add mISDN DSP")
1b2b03f8e514 ("Add mISDN core files")
04578dd330f1 ("Define AF_ISDN and PF_ISDN")
e4ac9bc1f668 ("Add mISDN driver")
None of them added a Documentation/isdn/mISDN.cert file.
Also, whatever were supposed to be written there on that time,
probably doesn't make any sense nowadays, as I doubt isdn would
have any massive changes.
So, let's just get rid of the broken reference, in order to
shut up a warning produced by ./scripts/documentation-file-ref-check.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
drivers/isdn/mISDN/dsp_core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/isdn/mISDN/dsp_core.c b/drivers/isdn/mISDN/dsp_core.c
index cd036e87335a..038e72a84b33 100644
--- a/drivers/isdn/mISDN/dsp_core.c
+++ b/drivers/isdn/mISDN/dsp_core.c
@@ -4,8 +4,6 @@
* Karsten Keil (keil@isdn4linux.de)
*
* This file is (c) under GNU PUBLIC LICENSE
- * For changes and modifications please read
- * ../../../Documentation/isdn/mISDN.cert
*
* Thanks to Karsten Keil (great drivers)
* Cologne Chip (great chips)
--
2.21.0
^ permalink raw reply related
* [PATCH v2 17/22] docs: net: sja1105.rst: fix table format
From: Mauro Carvalho Chehab @ 2019-06-04 14:17 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, David S. Miller, Vladimir Oltean,
Florian Fainelli, netdev
In-Reply-To: <cover.1559656538.git.mchehab+samsung@kernel.org>
There's a table there with produces two warnings when built
with Sphinx:
Documentation/networking/dsa/sja1105.rst:91: WARNING: Block quote ends without a blank line; unexpected unindent.
Documentation/networking/dsa/sja1105.rst:91: WARNING: Block quote ends without a blank line; unexpected unindent.
It will still produce a table, but the html output is wrong, as
it won't interpret the second line as the continuation for the
first ones, because identation doesn't match.
After the change, the output looks a way better and we got rid
of two warnings.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Vladimir Oltean <olteanv@gmail.com>
---
Documentation/networking/dsa/sja1105.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/networking/dsa/sja1105.rst b/Documentation/networking/dsa/sja1105.rst
index ea7bac438cfd..cb2858dece93 100644
--- a/Documentation/networking/dsa/sja1105.rst
+++ b/Documentation/networking/dsa/sja1105.rst
@@ -86,13 +86,13 @@ functionality.
The following traffic modes are supported over the switch netdevices:
+--------------------+------------+------------------+------------------+
-| | Standalone | Bridged with | Bridged with |
-| | ports | vlan_filtering 0 | vlan_filtering 1 |
+| | Standalone | Bridged with | Bridged with |
+| | ports | vlan_filtering 0 | vlan_filtering 1 |
+====================+============+==================+==================+
| Regular traffic | Yes | Yes | No (use master) |
+--------------------+------------+------------------+------------------+
| Management traffic | Yes | Yes | Yes |
-| (BPDU, PTP) | | | |
+| (BPDU, PTP) | | | |
+--------------------+------------+------------------+------------------+
Switching features
--
2.21.0
^ permalink raw reply related
* [PATCH v2 10/22] docs: vm: hmm.rst: fix some warnings
From: Mauro Carvalho Chehab @ 2019-06-04 14:17 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Jérôme Glisse, linux-mm
In-Reply-To: <cover.1559656538.git.mchehab+samsung@kernel.org>
Documentation/vm/hmm.rst:292: WARNING: Unexpected indentation.
Documentation/vm/hmm.rst:300: WARNING: Unexpected indentation.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/vm/hmm.rst | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst
index 7cdf7282e022..f22bb5fb5eec 100644
--- a/Documentation/vm/hmm.rst
+++ b/Documentation/vm/hmm.rst
@@ -283,7 +283,8 @@ The hmm_range struct has 2 fields default_flags and pfn_flags_mask that allows
to set fault or snapshot policy for a whole range instead of having to set them
for each entries in the range.
-For instance if the device flags for device entries are:
+For instance if the device flags for device entries are::
+
VALID (1 << 63)
WRITE (1 << 62)
--
2.21.0
^ permalink raw reply related
* [PATCH v2 09/22] docs: zh_CN: avoid duplicate citation references
From: Mauro Carvalho Chehab @ 2019-06-04 14:17 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Harry Wei, Alex Shi
In-Reply-To: <cover.1559656538.git.mchehab+samsung@kernel.org>
Documentation/process/management-style.rst:35: WARNING: duplicate label decisions, other instance in Documentation/translations/zh_CN/process/management-style.rst
Documentation/process/programming-language.rst:37: WARNING: duplicate citation c-language, other instance in Documentation/translations/zh_CN/process/programming-language.rst
Documentation/process/programming-language.rst:38: WARNING: duplicate citation gcc, other instance in Documentation/translations/zh_CN/process/programming-language.rst
Documentation/process/programming-language.rst:39: WARNING: duplicate citation clang, other instance in Documentation/translations/zh_CN/process/programming-language.rst
Documentation/process/programming-language.rst:40: WARNING: duplicate citation icc, other instance in Documentation/translations/zh_CN/process/programming-language.rst
Documentation/process/programming-language.rst:41: WARNING: duplicate citation gcc-c-dialect-options, other instance in Documentation/translations/zh_CN/process/programming-language.rst
Documentation/process/programming-language.rst:42: WARNING: duplicate citation gnu-extensions, other instance in Documentation/translations/zh_CN/process/programming-language.rst
Documentation/process/programming-language.rst:43: WARNING: duplicate citation gcc-attribute-syntax, other instance in Documentation/translations/zh_CN/process/programming-language.rst
Documentation/process/programming-language.rst:44: WARNING: duplicate citation n2049, other instance in Documentation/translations/zh_CN/process/programming-language.rst
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
.../zh_CN/process/management-style.rst | 4 +-
.../zh_CN/process/programming-language.rst | 59 ++++++++++++++-----
2 files changed, 47 insertions(+), 16 deletions(-)
diff --git a/Documentation/translations/zh_CN/process/management-style.rst b/Documentation/translations/zh_CN/process/management-style.rst
index a181fa56d19e..c6a5bb285797 100644
--- a/Documentation/translations/zh_CN/process/management-style.rst
+++ b/Documentation/translations/zh_CN/process/management-style.rst
@@ -28,7 +28,7 @@ Linux内核管理风格
不管怎样，这里是：
-.. _decisions:
+.. _cn_decisions:
1）决策
-------
@@ -108,7 +108,7 @@ Linux内核管理风格
但是，为了做好作为内核管理者的准备，最好记住不要烧掉任何桥梁，不要轰炸任何
无辜的村民，也不要疏远太多的内核开发人员。事实证明，疏远人是相当容易的，而
亲近一个疏远的人是很难的。因此，“疏远”立即属于“不可逆”的范畴，并根据
-:ref:`decisions` 成为绝不可以做的事情。
+:ref:`cn_decisions` 成为绝不可以做的事情。
这里只有几个简单的规则：
diff --git a/Documentation/translations/zh_CN/process/programming-language.rst b/Documentation/translations/zh_CN/process/programming-language.rst
index 51fd4ef48ea1..22b0e68c8360 100644
--- a/Documentation/translations/zh_CN/process/programming-language.rst
+++ b/Documentation/translations/zh_CN/process/programming-language.rst
@@ -8,21 +8,21 @@
程序设计语言
============
-内核是用C语言 [c-language]_ 编写的。更准确地说，内核通常是用 ``gcc`` [gcc]_
-在 ``-std=gnu89`` [gcc-c-dialect-options]_ 下编译的：ISO C90的 GNU 方言（
+内核是用C语言 :ref:`c-language <cn_c-language>` 编写的。更准确地说，内核通常是用 ``gcc`` :ref:`gcc <cn_gcc>`
+在 ``-std=gnu89`` :ref:`gcc-c-dialect-options <cn_gcc-c-dialect-options>` 下编译的：ISO C90的 GNU 方言（
包括一些C99特性）
-这种方言包含对语言 [gnu-extensions]_ 的许多扩展，当然，它们许多都在内核中使用。
+这种方言包含对语言 :ref:`gnu-extensions <cn_gnu-extensions>` 的许多扩展，当然，它们许多都在内核中使用。
-对于一些体系结构，有一些使用 ``clang`` [clang]_ 和 ``icc`` [icc]_ 编译内核
+对于一些体系结构，有一些使用 ``clang`` :ref:`clang <cn_clang>` 和 ``icc`` :ref:`icc <cn_icc>` 编译内核
的支持，尽管在编写此文档时还没有完成，仍需要第三方补丁。
属性
----
-在整个内核中使用的一个常见扩展是属性（attributes） [gcc-attribute-syntax]_
+在整个内核中使用的一个常见扩展是属性（attributes） :ref:`gcc-attribute-syntax <cn_gcc-attribute-syntax>`
属性允许将实现定义的语义引入语言实体（如变量、函数或类型），而无需对语言进行
-重大的语法更改（例如添加新关键字） [n2049]_
+重大的语法更改（例如添加新关键字） :ref:`n2049 <cn_n2049>`
在某些情况下，属性是可选的（即不支持这些属性的编译器仍然应该生成正确的代码，
即使其速度较慢或执行的编译时检查/诊断次数不够）
@@ -31,11 +31,42 @@
``__attribute__((__pure__))`` ），以检测可以使用哪些关键字和/或缩短代码, 具体
请参阅 ``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
+.. _cn_c-language:
+
+c-language
+ http://www.open-std.org/jtc1/sc22/wg14/www/standards
+
+.. _cn_gcc:
+
+gcc
+ https://gcc.gnu.org
+
+.. _cn_clang:
+
+clang
+ https://clang.llvm.org
+
+.. _cn_icc:
+
+icc
+ https://software.intel.com/en-us/c-compilers
+
+.. _cn_gcc-c-dialect-options:
+
+c-dialect-options
+ https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html
+
+.. _cn_gnu-extensions:
+
+gnu-extensions
+ https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html
+
+.. _cn_gcc-attribute-syntax:
+
+gcc-attribute-syntax
+ https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html
+
+.. _cn_n2049:
+
+n2049
+ http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2049.pdf
--
2.21.0
^ permalink raw reply related
* [PATCH v2 12/22] docs: gpio: driver.rst: fix a bad tag
From: Mauro Carvalho Chehab @ 2019-06-04 14:17 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Linus Walleij, Bartosz Golaszewski, linux-gpio
In-Reply-To: <cover.1559656538.git.mchehab+samsung@kernel.org>
With ReST, [foo]_ means a reference to foo, causing this warning:
Documentation/driver-api/gpio/driver.rst:419: WARNING: Unknown target name: "devm".
Fix it by using a literal for the name.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/driver-api/gpio/driver.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst
index 58036c2d84d2..4af9aae724f0 100644
--- a/Documentation/driver-api/gpio/driver.rst
+++ b/Documentation/driver-api/gpio/driver.rst
@@ -418,7 +418,7 @@ symbol:
If there is a need to exclude certain GPIO lines from the IRQ domain handled by
these helpers, we can set .irq.need_valid_mask of the gpiochip before
-[devm_]gpiochip_add_data() is called. This allocates an .irq.valid_mask with as
+``[devm_]gpiochip_add_data()`` is called. This allocates an .irq.valid_mask with as
many bits set as there are GPIO lines in the chip, each bit representing line
0..n-1. Drivers can exclude GPIO lines by clearing bits from this mask. The mask
must be filled in before gpiochip_irqchip_add() or gpiochip_irqchip_add_nested()
--
2.21.0
^ permalink raw reply related
* [PATCH v2 04/22] docs: mm: numaperf.rst: get rid of a build warning
From: Mauro Carvalho Chehab @ 2019-06-04 14:17 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Mike Rapoport, Jonathan Cameron,
Greg Kroah-Hartman, Keith Busch
In-Reply-To: <cover.1559656538.git.mchehab+samsung@kernel.org>
When building it, it gets this warning:
Documentation/admin-guide/mm/numaperf.rst:168: WARNING: Footnote [1] is not referenced.
The problem is that this is not really a reference, as it is not
mentioned within the documentation.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/admin-guide/mm/numaperf.rst | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/mm/numaperf.rst b/Documentation/admin-guide/mm/numaperf.rst
index c067ed145158..a80c3c37226e 100644
--- a/Documentation/admin-guide/mm/numaperf.rst
+++ b/Documentation/admin-guide/mm/numaperf.rst
@@ -165,5 +165,6 @@ write-through caching.
========
See Also
========
-.. [1] https://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf
- Section 5.2.27
+
+[1] https://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf
+- Section 5.2.27
--
2.21.0
^ permalink raw reply related
* [PATCH v2 14/22] docs: security: trusted-encrypted.rst: fix code-block tag
From: Mauro Carvalho Chehab @ 2019-06-04 14:17 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Mimi Zohar, James Bottomley, Jarkko Sakkinen,
linux-integrity, keyrings, James Morris
In-Reply-To: <cover.1559656538.git.mchehab+samsung@kernel.org>
The code-block tag is at the wrong place, causing those
warnings:
Documentation/security/keys/trusted-encrypted.rst:112: WARNING: Literal block expected; none found.
Documentation/security/keys/trusted-encrypted.rst:121: WARNING: Unexpected indentation.
Documentation/security/keys/trusted-encrypted.rst:122: WARNING: Block quote ends without a blank line; unexpected unindent.
Documentation/security/keys/trusted-encrypted.rst:123: WARNING: Block quote ends without a blank line; unexpected unindent.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: James Morris <jamorris@linux.microsoft.com>
Acked-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
Documentation/security/keys/trusted-encrypted.rst | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
index 7b35fcb58933..50ac8bcd6970 100644
--- a/Documentation/security/keys/trusted-encrypted.rst
+++ b/Documentation/security/keys/trusted-encrypted.rst
@@ -107,12 +107,14 @@ Where::
Examples of trusted and encrypted key usage:
-Create and save a trusted key named "kmk" of length 32 bytes::
+Create and save a trusted key named "kmk" of length 32 bytes.
Note: When using a TPM 2.0 with a persistent key with handle 0x81000001,
append 'keyhandle=0x81000001' to statements between quotes, such as
"new 32 keyhandle=0x81000001".
+::
+
$ keyctl add trusted kmk "new 32" @u
440502848
--
2.21.0
^ permalink raw reply related
* [PATCH v2 01/22] ABI: sysfs-devices-system-cpu: point to the right docs
From: Mauro Carvalho Chehab @ 2019-06-04 14:17 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Thomas Gleixner, Greg Kroah-Hartman, Jon Masters,
Rafael J. Wysocki, Josh Poimboeuf, Jiri Kosina
In-Reply-To: <cover.1559656538.git.mchehab+samsung@kernel.org>
The cpuidle doc was split on two, one at the admin guide
and another one at the driver API guide. Instead of pointing
to a non-existent file, point to both (admin guide being
the first one).
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
Documentation/ABI/testing/sysfs-devices-system-cpu | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 1528239f69b2..87478ac6c2af 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -137,7 +137,8 @@ Description: Discover cpuidle policy and mechanism
current_governor: (RW) displays current idle policy. Users can
switch the governor at runtime by writing to this file.
- See files in Documentation/cpuidle/ for more information.
+ See Documentation/admin-guide/pm/cpuidle.rst and
+ Documentation/driver-api/pm/cpuidle.rst for more information.
What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/name
--
2.21.0
^ permalink raw reply related
* [PATCH v2 07/22] docs: amd-memory-encryption.rst get rid of warnings
From: Mauro Carvalho Chehab @ 2019-06-04 14:17 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Paolo Bonzini, Radim Krčmář, kvm
In-Reply-To: <cover.1559656538.git.mchehab+samsung@kernel.org>
Get rid of those warnings:
Documentation/virtual/kvm/amd-memory-encryption.rst:244: WARNING: Citation [white-paper] is not referenced.
Documentation/virtual/kvm/amd-memory-encryption.rst:246: WARNING: Citation [amd-apm] is not referenced.
Documentation/virtual/kvm/amd-memory-encryption.rst:247: WARNING: Citation [kvm-forum] is not referenced.
For references that aren't mentioned at the text by adding an
explicit reference to them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
---
Documentation/virtual/kvm/amd-memory-encryption.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/virtual/kvm/amd-memory-encryption.rst b/Documentation/virtual/kvm/amd-memory-encryption.rst
index 659bbc093b52..d18c97b4e140 100644
--- a/Documentation/virtual/kvm/amd-memory-encryption.rst
+++ b/Documentation/virtual/kvm/amd-memory-encryption.rst
@@ -241,6 +241,9 @@ Returns: 0 on success, -negative on error
References
==========
+
+See [white-paper]_, [api-spec]_, [amd-apm]_ and [kvm-forum]_ for more info.
+
.. [white-paper] http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
.. [api-spec] http://support.amd.com/TechDocs/55766_SEV-KM_API_Specification.pdf
.. [amd-apm] http://support.amd.com/TechDocs/24593.pdf (section 15.34)
--
2.21.0
^ permalink raw reply related
* [PATCH v2 08/22] gpu: i915.rst: Fix references to renamed files
From: Mauro Carvalho Chehab @ 2019-06-04 14:17 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Maarten Lankhorst, Maxime Ripard, Sean Paul, David Airlie,
Daniel Vetter, intel-gfx, dri-devel
In-Reply-To: <cover.1559656538.git.mchehab+samsung@kernel.org>
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function Hardware workarounds ./drivers/gpu/drm/i915/intel_workarounds.c' failed with return code 1
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function Logical Rings, Logical Ring Contexts and Execlists ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 1
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 2
Fixes: 112ed2d31a46 ("drm/i915: Move GraphicsTechnology files under gt/")
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/gpu/i915.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 055df45596c1..6c75380b2928 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -61,7 +61,7 @@ Intel GVT-g Host Support(vGPU device model)
Workarounds
-----------
-.. kernel-doc:: drivers/gpu/drm/i915/intel_workarounds.c
+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_workarounds.c
:doc: Hardware workarounds
Display Hardware Handling
@@ -379,10 +379,10 @@ User Batchbuffer Execution
Logical Rings, Logical Ring Contexts and Execlists
--------------------------------------------------
-.. kernel-doc:: drivers/gpu/drm/i915/intel_lrc.c
+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_lrc.c
:doc: Logical Rings, Logical Ring Contexts and Execlists
-.. kernel-doc:: drivers/gpu/drm/i915/intel_lrc.c
+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_lrc.c
:internal:
Global GTT views
--
2.21.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox