Re: [PATCH] Documentation: filesystems: remove reminiscences of POHMELFS

[Greg Kroah-Hartman]

On Wed, Sep 12, 2018 at 03:44:19PM +0300, Vladimir Zapolskiy wrote:
> The POHMELFS filesystem was removed in 2012 by commit 67435319866f8
> ("staging: pohmelfs: remove drivers/staging/pohmelfs") promising that
> a newer version will be included to the kernel, but unfortunately
> it didn't happen.
> 
> Since likely any delopment of the filesystem is halted, the change removes
> the abandoned POHMELFS documentation from the kernel tree.
> 
> Signed-off-by: Vladimir Zapolskiy 

I've taken this through the staging tree as that is where this code used
to live.  Thanks for the cleanup.

greg k-h

Re: [PATCH 1/3] usb: gadget: ccid: add support for USB CCID Gadget Device

[Greg Kroah-Hartman]

On Sun, May 27, 2018 at 07:48:47AM +0200, Marcus Folkesson wrote:
> On Sat, May 26, 2018 at 10:56:52PM +0200, Greg Kroah-Hartman wrote:
> > On Sat, May 26, 2018 at 10:33:59PM +0200, Marcus Folkesson wrote:
> > > Signed-off-by: Marcus Folkesson <marcus.folkes...@gmail.com>
> > 
> > I can't take patches without any changelog text.  And why would you
> > submit a patch over 1000 lines without any?
> 
> I'm sorry, obviously not much went well for me yesterday.
> The changlelog was "fixup:ed" away and now I noticed that my
> patch version history did not follow for v2.
> 
> Is it better to send a v3 with updated version history or wait for more
> comments?

Nah, that's fine, but I'll let Felipe decide as he is the one that has
to review this, not me.

thanks,

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

Re: [PATCH 1/3] usb: gadget: ccid: add support for USB CCID Gadget Device

[Greg Kroah-Hartman]

On Sat, May 26, 2018 at 10:33:59PM +0200, Marcus Folkesson wrote:
> Signed-off-by: Marcus Folkesson 

I can't take patches without any changelog text.  And why would you
submit a patch over 1000 lines without any?

Please fix.

thanks,

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

Re: [PATCH v2 1/5] PCI/AER: Define and allocate aer_stats structure for AER capable devices

[Greg Kroah-Hartman]

On Wed, May 23, 2018 at 10:58:04AM -0700, Rajat Jain wrote:
> ---
> v2: Fix the license header as per Greg's suggestions
> (Since there is disagreement with using "//" vs "/* */" for license
>  I decided to keep the one preferred by Linus, also used by others
>  in this directory)

The rules are pretty simple for how to do this, and they are documented
in Documentation/process/license-rules.rst, please just follow that like
the rest of the kernel has done.

thanks,

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

Re: [PATCH 1/5] PCI/AER: Define and allocate aer_stats structure for AER capable devices

[Greg Kroah-Hartman]

On Tue, May 22, 2018 at 03:28:01PM -0700, Rajat Jain wrote:
> --- /dev/null
> +++ b/drivers/pci/pcie/aer/aerdrv_stats.c
> @@ -0,0 +1,64 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + *  Copyright (C) 2018 Google Inc, All Rights Reserved.
> + *  Rajat Jain (raja...@google.com)

Google has the copyright, not you, right?  You might want to make that a
bit more explicit by putting a blank line somewhere here...

> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.

If you have a SPDX line, you do not need this paragraph.  Please drop it
so we don't have to delete it later on.

thanks,

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

Re: [PATCH 3/5] PCP/AER: Add sysfs attributes to provide breakdown of AERs

[Greg Kroah-Hartman]

On Tue, May 22, 2018 at 03:28:03PM -0700, Rajat Jain wrote:
> Add sysfs attributes to provide breakdown of the AERs seen,
> into different type of correctable or uncorrectable errors:
> 
> dev_breakdown_correctable
> dev_breakdown_uncorrectable
> 
> Signed-off-by: Rajat Jain 
> ---
>  drivers/pci/pcie/aer/aerdrv.h  |  6 ++
>  drivers/pci/pcie/aer/aerdrv_errprint.c |  6 --
>  drivers/pci/pcie/aer/aerdrv_stats.c| 25 +
>  3 files changed, 35 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/pcie/aer/aerdrv.h b/drivers/pci/pcie/aer/aerdrv.h
> index b5d5ad6f2c03..048fbd7c9633 100644
> --- a/drivers/pci/pcie/aer/aerdrv.h
> +++ b/drivers/pci/pcie/aer/aerdrv.h
> @@ -89,6 +89,12 @@ int pci_aer_stats_init(struct pci_dev *pdev);
>  void pci_aer_stats_exit(struct pci_dev *pdev);
>  void pci_dev_aer_stats_incr(struct pci_dev *pdev, struct aer_err_info *info);
>  
> +extern const char
> +*aer_correctable_error_string[AER_MAX_TYPEOF_CORRECTABLE_ERRS];
> +
> +extern const char
> +*aer_uncorrectable_error_string[AER_MAX_TYPEOF_UNCORRECTABLE_ERRS];
> +
>  #ifdef CONFIG_ACPI_APEI
>  int pcie_aer_get_firmware_first(struct pci_dev *pci_dev);
>  #else
> diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c 
> b/drivers/pci/pcie/aer/aerdrv_errprint.c
> index 5e8b98deda08..5585f309f1a8 100644
> --- a/drivers/pci/pcie/aer/aerdrv_errprint.c
> +++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
> @@ -68,7 +68,8 @@ static const char *aer_error_layer[] = {
>   "Transaction Layer"
>  };
>  
> -static const char *aer_correctable_error_string[] = {
> +const char
> +*aer_correctable_error_string[AER_MAX_TYPEOF_CORRECTABLE_ERRS] = {
>   "Receiver Error",   /* Bit Position 0   */
>   NULL,
>   NULL,
> @@ -87,7 +88,8 @@ static const char *aer_correctable_error_string[] = {
>   "Header Log Overflow",  /* Bit Position 15  */
>  };
>  
> -static const char *aer_uncorrectable_error_string[] = {
> +const char
> +*aer_uncorrectable_error_string[AER_MAX_TYPEOF_UNCORRECTABLE_ERRS] = {
>   "Undefined",/* Bit Position 0   */
>   NULL,
>   NULL,
> diff --git a/drivers/pci/pcie/aer/aerdrv_stats.c 
> b/drivers/pci/pcie/aer/aerdrv_stats.c
> index 87b7119d0a86..5f0a6e144f56 100644
> --- a/drivers/pci/pcie/aer/aerdrv_stats.c
> +++ b/drivers/pci/pcie/aer/aerdrv_stats.c
> @@ -61,10 +61,35 @@ aer_stats_aggregate_attr(dev_total_cor_errs);
>  aer_stats_aggregate_attr(dev_total_fatal_errs);
>  aer_stats_aggregate_attr(dev_total_nonfatal_errs);
>  
> +#define aer_stats_breakdown_attr(field, stats_array, strings_array)  
>   \
> + static ssize_t \
> + field##_show(struct device *dev, struct device_attribute *attr,\
> +  char *buf)\
> +{
>   \
> + unsigned int i;\
> + char *str = buf;   \
> + struct pci_dev *pdev = to_pci_dev(dev);\
> + u64 *stats = pdev->aer_stats->stats_array; \
> + for (i = 0; i < ARRAY_SIZE(strings_array); i++) {  \
> + if (strings_array[i])  \
> + str += sprintf(str, "%s = 0x%llx\n",   \
> +strings_array[i], stats[i]);\
> + }  \
> + return str-buf;\
> +}
>   \

Again with the tabs instead of spaces please.

thanks,

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

Re: [PATCH 2/5] PCI/AER: Add sysfs stats for AER capable devices

[Greg Kroah-Hartman]

On Tue, May 22, 2018 at 03:28:02PM -0700, Rajat Jain wrote:
> +#define aer_stats_aggregate_attr(field)  
>   \
> + static ssize_t \
> + field##_show(struct device *dev, struct device_attribute *attr,\
> +  char *buf)\
> +{
>   \
> + struct pci_dev *pdev = to_pci_dev(dev);\
> + return sprintf(buf, "0x%llx\n", pdev->aer_stats->field);   \
> +}
>   \

Use tabs at the end please, otherwise your trailing \ look horrid.

> +static DEVICE_ATTR_RO(field)
> +
> +aer_stats_aggregate_attr(dev_total_cor_errs);
> +aer_stats_aggregate_attr(dev_total_fatal_errs);
> +aer_stats_aggregate_attr(dev_total_nonfatal_errs);
> +
> +static struct attribute *aer_stats_attrs[] __ro_after_init = {
> + _attr_dev_total_cor_errs.attr,
> + _attr_dev_total_fatal_errs.attr,
> + _attr_dev_total_nonfatal_errs.attr,
> + NULL
> +};
> +
> +static umode_t aer_stats_attrs_are_visible(struct kobject *kobj,
> +struct attribute *a, int n)
> +{
> + struct device *dev = kobj_to_dev(kobj);
> + struct pci_dev *pdev = to_pci_dev(dev);
> +
> + if (!pdev->aer_stats)
> + return 0;
> +
> + return a->mode;
> +}
> +
> +const struct attribute_group aer_stats_attr_group = {
> + .name  = "aer_stats",
> + .attrs  = aer_stats_attrs,
> + .is_visible = aer_stats_attrs_are_visible,
> +};
> +
> +void pci_dev_aer_stats_incr(struct pci_dev *pdev, struct aer_err_info *info)
> +{
> + int status, i, max = -1;
> + u64 *counter = NULL;
> + struct aer_stats *aer_stats = pdev->aer_stats;
> +
> + if (unlikely(!aer_stats))
> + return;

Can you measure the speed difference with and without that unlikely()
macro?  If not, please don't use it.  Hint, the cpu and compiler are
always always better at this than we are...

thanks,

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

Re: [PATCH 5/5] Documentation/PCI: Add details of PCI AER statistics

[Greg Kroah-Hartman]

On Tue, May 22, 2018 at 03:28:05PM -0700, Rajat Jain wrote:
> Add the PCI AER statistics details to
> Documentation/PCI/pcieaer-howto.txt
> 
> Signed-off-by: Rajat Jain 
> ---
>  Documentation/PCI/pcieaer-howto.txt | 35 +
>  1 file changed, 35 insertions(+)
> 
> diff --git a/Documentation/PCI/pcieaer-howto.txt 
> b/Documentation/PCI/pcieaer-howto.txt
> index acd06bb8..86ee9f9ff5e1 100644
> --- a/Documentation/PCI/pcieaer-howto.txt
> +++ b/Documentation/PCI/pcieaer-howto.txt
> @@ -73,6 +73,41 @@ In the example, 'Requester ID' means the ID of the device 
> who sends
>  the error message to root port. Pls. refer to pci express specs for
>  other fields.
>  
> +2.4 AER statistics
> +
> +When AER messages are captured, the statistics are exposed via the following
> +sysfs attributes under the "aer_stats" folder for the device:
> +
> +2.4.1 Device sysfs Attributes
> +
> +These attributes show up under all the devices that are AER capable. These
> +indicate the errors "as seen by the device". Note that this may mean that if
> +an end point is causing problems, the AER counters may increment at its link
> +partner (e.g. root port) because the errors will be "seen" by the link 
> partner
> +and not the the problematic end point itself (which may report all counters
> +as 0 as it never saw any problems).
> +
> + * dev_total_cor_errs: number of correctable errors seen by the device.
> + * dev_total_fatal_errs: number of fatal uncorrectable errors seen by the 
> device.
> + * dev_total_nonfatal_errs: number of nonfatal uncorr errors seen by the 
> device.
> + * dev_breakdown_correctable: Provides a breakdown of different type of
> +  correctable errors seen.
> + * dev_breakdown_uncorrectable: Provides a breakdown of different type of
> +  uncorrectable errors seen.
> +
> +2.4.1 Rootport sysfs Attributes
> +
> +These attributes showup under only the rootports that are AER capable. These
> +indicate the number of error messages as "reported to" the rootport. Please 
> note
> +that the rootports also transmit (internally) the ERR_* messages for errors 
> seen
> +by the internal rootport PCI device, so these counters includes them and are
> +thus cumulative of all the error messages on the PCI hierarchy originating
> +at that root port.
> +
> + * rootport_total_cor_errs: number of ERR_COR messages reported to rootport.
> + * rootport_total_fatal_errs: number of ERR_FATAL messages reported to 
> rootport.
> + * rootport_total_nonfatal_errs: number of ERR_NONFATAL messages reporeted to
> + rootport.

These all belong in Documentation/ABI/ please.

thanks,

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

Re: [PATCH 2/5] PCI/AER: Add sysfs stats for AER capable devices

[Greg Kroah-Hartman]

On Tue, May 22, 2018 at 03:28:02PM -0700, Rajat Jain wrote:
> Add the following AER sysfs stats to represent the counters for each
> kind of error as seen by the device:
> 
> dev_total_cor_errs
> dev_total_fatal_errs
> dev_total_nonfatal_errs

You need Documentation/ABI/ updates for new sysfs files please.

thanks,

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

Re: [PATCH 03/18] docs: */index.rst: Add newer documents to their respective index.rst

[Greg Kroah-Hartman]

On Mon, May 07, 2018 at 06:35:39AM -0300, Mauro Carvalho Chehab wrote:
> A number of new docs were added, but they're currently not on
> the index.rst from the session they're supposed to be, causing
> Sphinx warnings.
> 
> Add them.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+sams...@kernel.org>

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/18] docs: driver-api: add clk documentation

[Greg Kroah-Hartman]

On Mon, May 07, 2018 at 06:35:44AM -0300, Mauro Carvalho Chehab wrote:
> The clk.rst is already in ReST format. So, move it to the
> driver-api guide, where it belongs.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+sams...@kernel.org>

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/18] docs: fix location of request_firmware & friends

[Greg Kroah-Hartman]

On Mon, May 07, 2018 at 06:35:38AM -0300, Mauro Carvalho Chehab wrote:
> commit 5d6d1ddd2730 ("firmware: move firmware loader into its own directory")
> and other commits renamed the old firmware_class.c file and split it
> into separate files, but documentation was not changed accordingly,
> causing Sphinx errors.
> 
> Change the location accordingly at the documentation files.
> 
> While here, add a missing entry at request_firmware.rst for
> release_firmware() function.
> 
> Fixes: 5d6d1ddd2730 ("firmware: move firmware loader into its own directory")
> Cc: Kees Cook <keesc...@chromium.org>
> Cc: Luis R. Rodriguez <mcg...@kernel.org>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+sams...@kernel.org>

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 17/18] docs: uio-howto.rst: use a code block to solve a warning

[Greg Kroah-Hartman]

On Mon, May 07, 2018 at 06:35:53AM -0300, Mauro Carvalho Chehab wrote:
> /devel/v4l/docs/Documentation/driver-api/uio-howto.rst:715: WARNING: 
> Unexpected indentation.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+sams...@kernel.org>

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 03/10] i3c: Add sysfs ABI spec

[Greg Kroah-Hartman]

On Wed, May 02, 2018 at 11:47:49AM +0200, Geert Uytterhoeven wrote:
> Hi Greg,
> 
> On Sun, Apr 29, 2018 at 3:37 PM, Greg Kroah-Hartman
> <gre...@linuxfoundation.org> wrote:
> > On Fri, Mar 30, 2018 at 09:47:44AM +0200, Boris Brezillon wrote:
> >> Document sysfs files/directories/symlinks exposed by the I3C subsystem.
> >>
> >> Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com>
> >> ---
> >> Changes in v2:
> >> - new patch
> >> ---
> >>  Documentation/ABI/testing/sysfs-bus-i3c | 95 
> >> +
> >>  1 file changed, 95 insertions(+)
> >>  create mode 100644 Documentation/ABI/testing/sysfs-bus-i3c
> >>
> >> diff --git a/Documentation/ABI/testing/sysfs-bus-i3c 
> >> b/Documentation/ABI/testing/sysfs-bus-i3c
> >> new file mode 100644
> >> index ..5e88cc093e0e
> >> --- /dev/null
> >> +++ b/Documentation/ABI/testing/sysfs-bus-i3c
> >> @@ -0,0 +1,95 @@
> >> +What:/sys/bus/i3c/devices/i3c-
> >> +KernelVersion:  4.16
> >
> > Wrong kernel versions :)
> 
> Do you update these when backporting to stable? ;-)

I'm not adding new features/subsystems to stable :)
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

[Greg Kroah-Hartman]

On Sun, Apr 29, 2018 at 12:15:11PM +0200, Rafał Miłecki wrote:
> On 29 April 2018 at 07:26, Greg Kroah-Hartman
> <gre...@linuxfoundation.org> wrote:
> > On Sat, Apr 28, 2018 at 11:25:17PM +0200, Rafał Miłecki wrote:
> >> Due to some maintainers *preferring* BSD-compatible license for DTS
> >> files [0], I was writing mine using ISC. I had no very special reason
> >> for it: I was choosing between BSD-2-Clause, MIT and ISC. I've chosen
> >> ISC as I read about its "removal of language deemed unnecessary".
> >>
> >> I took a moment to look at the new SPDX thing and noticed that:
> >> 1) File license-rules.rst provides "LICENSES/other/ISC" as an example
> >
> > Yeah, bad example, we should fix that text up.  Care to send a patch? :)
> 
> Sure. I see that license-rules.rst also refers to LICENSES/other/ZLib
> which also doesn't exist.
> 
> As "other" directory contains only GPL-1.0 and MPL-1.1 I guess one of
> these should be referenced.

See the patch set that Thomas has posted to hopefully resolve these
issues.  I think they are all now taken care of with that series.

> >> 2) License file LICENSES/other/ISC doesn't exist
> >> 3) ISC is listed as an *example* under the "Not recommended licenses"
> >
> > Yes, please don't use it if at all possible.
> >
> >> First of all, as ISC is used by some files in the Linux kernel, I
> >> think it's worth adding to the LICENSE/*/ISC.
> >
> > I see it is only used in a very small number of dts files.  Why not just
> > use BSD-2-Clause instead?  What do you find in ISC that is not available
> > to you with just BSD?
> 
> As said, I read about its "removal of language deemed unnecessary". I
> assumed that the simpler license text the better.

Simple up to a point, having loads of different licenses is a mess, as
you are finding out :)

> >> Secondly, it isn't 100% clear to me if ISC is preferred or not
> >> recommended. File license-rules.rst suggests the later by listing it
> >> as an example for "Not recommended". It's just an example though, so
> >> I'm not 100% sure without seeing it in either: "preferred" or "other"
> >> directories. Also if anyone finds it "Not recommended", can we get a
> >> short explanation why is it so, please?
> >
> > The license is functionally equalivant to BSD-2, so why would you want
> > to add more complexity here and have two licenses that are the same be
> > "recommended"?
> 
> I don't insist on it, I'm trying to figure out what's the best for the
> Linux community.
> 
> On the other hand I could ask why do we want more complexity by having
> MIT license. It's very similar to the BSD-2-Clause after all. AFAIK
> the only minor differences are that:
> 1) MIT clearly allows sublicensing
> 2) BSD 2-Clause clearly requires distributing *binaries* with
> copyrights + license text

I think you will find more dual-licensed MIT code in the tree already
than ISC, right?

And really, in the end, the odds of someone taking this code _out_ of
the tree and using it only under a non-GPLv2 license is slim, to none,
so it's best to just stick with the common licenses, as long as they
match what you wish the code to abide by.  As you want to follow what
MIT says, then just use that and all should be good, right?

thanks,

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

Re: [PATCH v4 00/10] Add the I3C subsystem

[Greg Kroah-Hartman]

On Mon, Apr 23, 2018 at 07:56:46PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Apr 23, 2018 at 07:38:14PM +0200, Boris Brezillon wrote:
> > Hi,
> > 
> > On Fri, 30 Mar 2018 09:47:41 +0200
> > Boris Brezillon <boris.brezil...@bootlin.com> wrote:
> > 
> > > This patch series is a proposal for a new I3C subsystem.
> > 
> > This v4 has been sent almost a month ago and I didn't get any feedback
> > so far apart from Rob's R-b. Greg, is there any chance we can get these
> > patches merged in 4.18? If not, could you tell me what should be
> > addressed/improved/reworked?
> 
> I'll look over it later this week, thanks.

At first glance, it would be great to have at least one other
reviewed-by or signed-off-by on the main code here.  I don't want to be
the only one to have to review it :)

thanks,

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

Re: [PATCH v4 03/10] i3c: Add sysfs ABI spec

[Greg Kroah-Hartman]

On Fri, Mar 30, 2018 at 09:47:44AM +0200, Boris Brezillon wrote:
> Document sysfs files/directories/symlinks exposed by the I3C subsystem.
> 
> Signed-off-by: Boris Brezillon 
> ---
> Changes in v2:
> - new patch
> ---
>  Documentation/ABI/testing/sysfs-bus-i3c | 95 
> +
>  1 file changed, 95 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-i3c
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-i3c 
> b/Documentation/ABI/testing/sysfs-bus-i3c
> new file mode 100644
> index ..5e88cc093e0e
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-i3c
> @@ -0,0 +1,95 @@
> +What:/sys/bus/i3c/devices/i3c-
> +KernelVersion:  4.16

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

Re: LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

[Greg Kroah-Hartman]

On Sat, Apr 28, 2018 at 11:25:17PM +0200, Rafał Miłecki wrote:
> Hi,
> 
> Due to some maintainers *preferring* BSD-compatible license for DTS
> files [0], I was writing mine using ISC. I had no very special reason
> for it: I was choosing between BSD-2-Clause, MIT and ISC. I've chosen
> ISC as I read about its "removal of language deemed unnecessary".
> 
> I took a moment to look at the new SPDX thing and noticed that:
> 1) File license-rules.rst provides "LICENSES/other/ISC" as an example

Yeah, bad example, we should fix that text up.  Care to send a patch? :)

> 2) License file LICENSES/other/ISC doesn't exist
> 3) ISC is listed as an *example* under the "Not recommended licenses"

Yes, please don't use it if at all possible.

> First of all, as ISC is used by some files in the Linux kernel, I
> think it's worth adding to the LICENSE/*/ISC.

I see it is only used in a very small number of dts files.  Why not just
use BSD-2-Clause instead?  What do you find in ISC that is not available
to you with just BSD?

> Secondly, it isn't 100% clear to me if ISC is preferred or not
> recommended. File license-rules.rst suggests the later by listing it
> as an example for "Not recommended". It's just an example though, so
> I'm not 100% sure without seeing it in either: "preferred" or "other"
> directories. Also if anyone finds it "Not recommended", can we get a
> short explanation why is it so, please?

The license is functionally equalivant to BSD-2, so why would you want
to add more complexity here and have two licenses that are the same be
"recommended"?

thanks,

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

Re: [PATCH v4 00/10] Add the I3C subsystem

[Greg Kroah-Hartman]

On Mon, Apr 23, 2018 at 07:38:14PM +0200, Boris Brezillon wrote:
> Hi,
> 
> On Fri, 30 Mar 2018 09:47:41 +0200
> Boris Brezillon  wrote:
> 
> > This patch series is a proposal for a new I3C subsystem.
> 
> This v4 has been sent almost a month ago and I didn't get any feedback
> so far apart from Rob's R-b. Greg, is there any chance we can get these
> patches merged in 4.18? If not, could you tell me what should be
> addressed/improved/reworked?

I'll look over it later this week, thanks.

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

Re: [PATCH v2 1/2] COPYING: create a new file with points to the Kernel license files

[Greg Kroah-Hartman]

On Fri, Mar 23, 2018 at 06:51:05AM -0300, Mauro Carvalho Chehab wrote:
> With the addition of SPDX patchset, the contents of COPYING file
> is now duplicated at two other files under LICENSE:
>   LICENSES/preferred/GPL-2.0
>   LICENSES/exceptions/Linux-syscall-note
> 
> It is easy to check that the contents of the licence written on
> those files are identical with COPYING using:
> 
>   $ diff -upr COPYING LICENSES/preferred/GPL-2.0
>   $ diff -upr COPYING LICENSES/exceptions/Linux-syscall-note|less
> 
> Also, a new file was added, with describes how SPDX should work at
> the Kernel source files:
>   Documentation/process/license-rules.rst
> 
> Instead fo having it copying the contents of two files, and not
> even mentioning the third one, replace it by a file whose content
> points to the other tree files, preserving the Kernel's license.
> 
> Adjust license-rules.rst accordingly.
> 
> Please notice that this file preserves the Kernel license as
> is, without any changes.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
> 
> Version 2:
>- Did some text changes at license-rules.rst, based on Matthew
>  Wilcox review.

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] COPYING: use the new text with points to the license files

[Greg Kroah-Hartman]

On Thu, Mar 22, 2018 at 06:54:14AM -0300, Mauro Carvalho Chehab wrote:
> Now that we have a new COPYING file with points to the
> Linux license files, replace it with the old content.
> 
> This patch does:
>  1 file changed, 0 insertions(+), 0 deletions(-)
>  rename COPYING.new => COPYING (100%)
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] COPYING: create a new file with points to the Kernel license files

[Greg Kroah-Hartman]

On Thu, Mar 22, 2018 at 06:54:13AM -0300, Mauro Carvalho Chehab wrote:
> With the addition of SPDX patchset, the contents of COPYING file
> is now duplicated at two other files under LICENSE:
>   LICENSES/preferred/GPL-2.0
>   LICENSES/exceptions/Linux-syscall-note
> 
> It is easy to check that the contents of the licence written on
> those files are identical with COPYING using:
> 
>   $ diff -upr COPYING LICENSES/preferred/GPL-2.0
>   $ diff -upr COPYING LICENSES/exceptions/Linux-syscall-note|less
> 
> Also, a new file was added, with describes how SPDX should work at
> the Kernel source files:
>   Documentation/process/license-rules.rst
> 
> Instead fo having it copying the contents of two files, and not
> even mentioning the third one, replace it by a file whose content
> points to the other tree files, preserving the Kernel's license.
> 
> Adjust license-rules.rst accordingly.
> 
> Please notice that this file preserves the Kernel license as
> is, without any changes.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] documentation: add my name to kernel driver statement

[Greg Kroah-Hartman]

On Sun, Mar 04, 2018 at 10:18:14PM +0200, Aaro Koskinen wrote:
> Add my name to kernel driver statement.

Thanks for doing this!

> Signed-off-by: Aaro Koskinen <aaro.koski...@iki.fi>

Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

Jon, can you pick this up or do you need me to forward this to you?

thanks,

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

Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure

[Greg Kroah-Hartman]

On Wed, Feb 21, 2018 at 03:22:48PM +0100, Boris Brezillon wrote:
> Hi Greg,
> 
> On Tue, 19 Dec 2017 10:36:43 +0100
> Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote:
> 
> > On Tue, Dec 19, 2017 at 10:28:58AM +0100, Boris Brezillon wrote:
> > > On Tue, 19 Dec 2017 10:21:19 +0100
> > > Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote:
> > >   
> > > > On Tue, Dec 19, 2017 at 10:13:36AM +0100, Boris Brezillon wrote:  
> > > > > On Tue, 19 Dec 2017 10:09:00 +0100
> > > > > Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> > > > > 
> > > > > > On Tue, 19 Dec 2017 09:52:50 +0100
> > > > > > Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote:
> > > > > > 
> > > > > > > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:  
> > > > > > > 
> > > > > > > > +/**
> > > > > > > > + * i3c_device_match_id() - Find the I3C device ID entry 
> > > > > > > > matching an I3C dev
> > > > > > > > + * @i3cdev: the I3C device we're searching a match for
> > > > > > > > + * @id_table: the I3C device ID table
> > > > > > > > + *
> > > > > > > > + * Return: a pointer to the first entry matching @i3cdev, or 
> > > > > > > > NULL if there's
> > > > > > > > + *no match.
> > > > > > > > + */
> > > > > > > > +const struct i3c_device_id *
> > > > > > > > +i3c_device_match_id(struct i3c_device *i3cdev,
> > > > > > > > +   const struct i3c_device_id *id_table)
> > > > > > > > +{
> > > > > > > > +   const struct i3c_device_id *id;
> > > > > > > > +
> > > > > > > > +   /*
> > > > > > > > +* The lower 32bits of the provisional ID is just 
> > > > > > > > filled with a random
> > > > > > > > +* value, try to match using DCR info.
> > > > > > > > +*/
> > > > > > > > +   if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> > > > > > > > +   u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> > > > > > > > +   u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> > > > > > > > +   u16 ext_info = 
> > > > > > > > I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> > > > > > > > +
> > > > > > > > +   /* First try to match by manufacturer/part ID. 
> > > > > > > > */
> > > > > > > > +   for (id = id_table; id->match_flags != 0; id++) 
> > > > > > > > {
> > > > > > > > +   if ((id->match_flags & 
> > > > > > > > I3C_MATCH_MANUF_AND_PART) !=
> > > > > > > > +   I3C_MATCH_MANUF_AND_PART)
> > > > > > > > +   continue;
> > > > > > > > +
> > > > > > > > +   if (manuf != id->manuf_id || part != 
> > > > > > > > id->part_id)
> > > > > > > > +   continue;
> > > > > > > > +
> > > > > > > > +   if ((id->match_flags & 
> > > > > > > > I3C_MATCH_EXTRA_INFO) &&
> > > > > > > > +   ext_info != id->extra_info)
> > > > > > > > +   continue;
> > > > > > > > +
> > > > > > > > +   return id;
> > > > > > > > +   }
> > > > > > > > +   }
> > > > > > > > +
> > > > > > > > +   /* Fallback to DCR match. */
> > > > > > > > +   for (id = id_table; id->match_flags != 0; id++) {
> > > > > > > > +   if ((id->match_flags & I3C_MATCH_DCR) &&
> > > > > > > > +   id->dcr == i3cdev->info.dcr)
> > > > > > > > +

Re: [PATCH v6 00/11] Intel SGX Driver

[Greg Kroah-Hartman]

On Thu, Jan 04, 2018 at 03:17:24PM +0100, Cedric Blancher wrote:
> So how does this protect against the MELTDOWN attack (CVE-2017-5754)
> and the MELTATOMBOMBA4 worm which uses this exploit?

It has nothing to do with it at all, sorry.

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

Re: Maintainer docs for patch merging

[Greg Kroah-Hartman]

On Wed, Dec 20, 2017 at 11:25:41AM +1100, Tobin C. Harding wrote:
> Hi,
> 
> Recently we started a maintainer book (merged into Jonathan's docs-next
> branch).
> 
> Would any current maintainers please be willing to explain how they go
> about generating the automated emails one often receives when a patch
> [set] is applied.
> 
> This may also be related to tree/branch management for maintainers
> kernel.org shows some people like to use multiple trees and some use
> branches? 
> 
> If deemed relevant we could add a section to the new book (and I'd also
> like to know how to do it for my own tree please so I can copy ;)
> 
> I have CC'd Greg and Andrew because they seem to have a system in place
> for this.

I "stole" Andrew's scripts for this a long time ago.  I guess I can
write up something "real" for the documentation so that others can see
the shell mess that drives those emails :)

> No rush on this, I know Christmas is soon.

Yeah, this will have to wait until mid January at the earliest...

thanks,

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

Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure

[Greg Kroah-Hartman]

On Tue, Dec 19, 2017 at 10:28:58AM +0100, Boris Brezillon wrote:
> On Tue, 19 Dec 2017 10:21:19 +0100
> Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote:
> 
> > On Tue, Dec 19, 2017 at 10:13:36AM +0100, Boris Brezillon wrote:
> > > On Tue, 19 Dec 2017 10:09:00 +0100
> > > Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> > >   
> > > > On Tue, 19 Dec 2017 09:52:50 +0100
> > > > Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote:
> > > >   
> > > > > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:
> > > > > > +/**
> > > > > > + * i3c_device_match_id() - Find the I3C device ID entry matching 
> > > > > > an I3C dev
> > > > > > + * @i3cdev: the I3C device we're searching a match for
> > > > > > + * @id_table: the I3C device ID table
> > > > > > + *
> > > > > > + * Return: a pointer to the first entry matching @i3cdev, or NULL 
> > > > > > if there's
> > > > > > + *no match.
> > > > > > + */
> > > > > > +const struct i3c_device_id *
> > > > > > +i3c_device_match_id(struct i3c_device *i3cdev,
> > > > > > +   const struct i3c_device_id *id_table)
> > > > > > +{
> > > > > > +   const struct i3c_device_id *id;
> > > > > > +
> > > > > > +   /*
> > > > > > +* The lower 32bits of the provisional ID is just filled with a 
> > > > > > random
> > > > > > +* value, try to match using DCR info.
> > > > > > +*/
> > > > > > +   if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> > > > > > +   u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> > > > > > +   u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> > > > > > +   u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> > > > > > +
> > > > > > +   /* First try to match by manufacturer/part ID. */
> > > > > > +   for (id = id_table; id->match_flags != 0; id++) {
> > > > > > +   if ((id->match_flags & 
> > > > > > I3C_MATCH_MANUF_AND_PART) !=
> > > > > > +   I3C_MATCH_MANUF_AND_PART)
> > > > > > +   continue;
> > > > > > +
> > > > > > +   if (manuf != id->manuf_id || part != 
> > > > > > id->part_id)
> > > > > > +   continue;
> > > > > > +
> > > > > > +   if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
> > > > > > +   ext_info != id->extra_info)
> > > > > > +   continue;
> > > > > > +
> > > > > > +   return id;
> > > > > > +   }
> > > > > > +   }
> > > > > > +
> > > > > > +   /* Fallback to DCR match. */
> > > > > > +   for (id = id_table; id->match_flags != 0; id++) {
> > > > > > +   if ((id->match_flags & I3C_MATCH_DCR) &&
> > > > > > +   id->dcr == i3cdev->info.dcr)
> > > > > > +   return id;
> > > > > > +   }
> > > > > > +
> > > > > > +   return NULL;
> > > > > > +}
> > > > > > +EXPORT_SYMBOL_GPL(i3c_device_match_id);  
> > > > > 
> > > > > I just picked one random export here, but it feels like you are
> > > > > exporting a bunch of symbols you don't need to.  Why would something
> > > > > outside of the i3c "core" need to call this function?
> > > > 
> > > > Because I'm not passing the i3c_device_id to the ->probe() method, and
> > > > if the driver is supporting different variants of the device, it may
> > > > want to know which one is being probed.
> > > > 
> > > > I considered retrieving this information in the core just before probing
> > > > the driver and passing it to the ->probe() function, but it means
> > > > having an extra i3c_device_match_id() call for everyone even those who
> > > > don

Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure

[Greg Kroah-Hartman]

On Tue, Dec 19, 2017 at 10:13:36AM +0100, Boris Brezillon wrote:
> On Tue, 19 Dec 2017 10:09:00 +0100
> Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> 
> > On Tue, 19 Dec 2017 09:52:50 +0100
> > Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote:
> > 
> > > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:  
> > > > +/**
> > > > + * i3c_device_match_id() - Find the I3C device ID entry matching an 
> > > > I3C dev
> > > > + * @i3cdev: the I3C device we're searching a match for
> > > > + * @id_table: the I3C device ID table
> > > > + *
> > > > + * Return: a pointer to the first entry matching @i3cdev, or NULL if 
> > > > there's
> > > > + *no match.
> > > > + */
> > > > +const struct i3c_device_id *
> > > > +i3c_device_match_id(struct i3c_device *i3cdev,
> > > > +   const struct i3c_device_id *id_table)
> > > > +{
> > > > +   const struct i3c_device_id *id;
> > > > +
> > > > +   /*
> > > > +* The lower 32bits of the provisional ID is just filled with a 
> > > > random
> > > > +* value, try to match using DCR info.
> > > > +*/
> > > > +   if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> > > > +   u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> > > > +   u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> > > > +   u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> > > > +
> > > > +   /* First try to match by manufacturer/part ID. */
> > > > +   for (id = id_table; id->match_flags != 0; id++) {
> > > > +   if ((id->match_flags & 
> > > > I3C_MATCH_MANUF_AND_PART) !=
> > > > +   I3C_MATCH_MANUF_AND_PART)
> > > > +   continue;
> > > > +
> > > > +   if (manuf != id->manuf_id || part != 
> > > > id->part_id)
> > > > +   continue;
> > > > +
> > > > +   if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
> > > > +   ext_info != id->extra_info)
> > > > +   continue;
> > > > +
> > > > +   return id;
> > > > +   }
> > > > +   }
> > > > +
> > > > +   /* Fallback to DCR match. */
> > > > +   for (id = id_table; id->match_flags != 0; id++) {
> > > > +   if ((id->match_flags & I3C_MATCH_DCR) &&
> > > > +   id->dcr == i3cdev->info.dcr)
> > > > +   return id;
> > > > +   }
> > > > +
> > > > +   return NULL;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(i3c_device_match_id);
> > > 
> > > I just picked one random export here, but it feels like you are
> > > exporting a bunch of symbols you don't need to.  Why would something
> > > outside of the i3c "core" need to call this function?  
> > 
> > Because I'm not passing the i3c_device_id to the ->probe() method, and
> > if the driver is supporting different variants of the device, it may
> > want to know which one is being probed.
> > 
> > I considered retrieving this information in the core just before probing
> > the driver and passing it to the ->probe() function, but it means
> > having an extra i3c_device_match_id() call for everyone even those who
> > don't care about the device_id information, so I thought exporting this
> > function was a good alternative (device drivers can use it when they
> > actually need to retrieve the device_id).
> > 
> > Anyway, that's something I can change if you think passing the
> > i3c_device_id to the ->probe() method is preferable.
> > 
> > > Have you looked
> > > to see if you really have callers for everything you are exporting?  
> > 
> > Yes, I tried to only export functions that I think will be needed by
> > I3C device drivers and I3C master drivers. Note that I didn't post the
> > dummy device driver I developed to test the framework (partly because
> > this is 
> 
> Sorry, I hit the send button before finishing my sentence :-).
> 
> "
> Note that I didn't post the dummy device driver [1] I developed to test
> the framework (partly because the quality of the code does not meet
> mainline standards and I was ashamed of posting it publicly :-)), but
> this driver is using some of the exported functions.
> "

We don't export functions that has no in-kernel users :)

thanks,

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

Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure

[Greg Kroah-Hartman]

On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:
> +/**
> + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev
> + * @i3cdev: the I3C device we're searching a match for
> + * @id_table: the I3C device ID table
> + *
> + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's
> + *  no match.
> + */
> +const struct i3c_device_id *
> +i3c_device_match_id(struct i3c_device *i3cdev,
> + const struct i3c_device_id *id_table)
> +{
> + const struct i3c_device_id *id;
> +
> + /*
> +  * The lower 32bits of the provisional ID is just filled with a random
> +  * value, try to match using DCR info.
> +  */
> + if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> + u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> + u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> +
> + /* First try to match by manufacturer/part ID. */
> + for (id = id_table; id->match_flags != 0; id++) {
> + if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) !=
> + I3C_MATCH_MANUF_AND_PART)
> + continue;
> +
> + if (manuf != id->manuf_id || part != id->part_id)
> + continue;
> +
> + if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
> + ext_info != id->extra_info)
> + continue;
> +
> + return id;
> + }
> + }
> +
> + /* Fallback to DCR match. */
> + for (id = id_table; id->match_flags != 0; id++) {
> + if ((id->match_flags & I3C_MATCH_DCR) &&
> + id->dcr == i3cdev->info.dcr)
> + return id;
> + }
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(i3c_device_match_id);

I just picked one random export here, but it feels like you are
exporting a bunch of symbols you don't need to.  Why would something
outside of the i3c "core" need to call this function?  Have you looked
to see if you really have callers for everything you are exporting?

Other than that, the driver core interaction looks good now, nice job.

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

Re: [RFC 2/5] i3c: Add core I3C infrastructure

[Greg Kroah-Hartman]

On Wed, Dec 13, 2017 at 05:20:43PM +0100, Boris Brezillon wrote:
> Hi Greg,
> 
> On Tue, 1 Aug 2017 19:13:27 -0700
> Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote:
> 
> > > > > Unless you see a good reason to not use a R/W lock, I'd like to keep 
> > > > > it
> > > > > this way because master IPs are likely to implement advanced queuing
> > > > > mechanism (allows one to queue new transfers even if the master is
> > > > > already busy processing other requests), and serializing things at the
> > > > > framework level will just prevent us from using this kind of
> > > > > optimization.
> > > > 
> > > > Unless you can prove otherwise, using a rw lock is almost always worse
> > > > than just a mutex.  
> > > 
> > > Is it still true when it's taken in non-exclusive mode most of the
> > > time, and the time you spend in the critical section is non-negligible?
> > > 
> > > I won't pretend I know better than you do what is preferable, it's just
> > > that the RW lock seemed appropriate to me for the situation I tried to
> > > described here.  
> > 
> > Again, measure it.  If you can't measure it, then don't use it.  Use a
> > simple lock instead.  Seriously, don't make it more complex until you
> > really have to.  It sounds like you didn't measure it at all, which
> > isn't good, please do so.
> > 
> 
> I'm resurrecting this thread because I finally had the time to implement
> message queuing in Cadence I3C master driver. So I did a test with 2
> I3C devices on the bus, and their drivers sending as much SDR messages
> as they can in 10s. Here are the results:
> 
>   |mutex|rwsem|
> ---
> dev1  |19087|29532|
> dev2  |19341|29118|
> ===
> total |38428|58650|
> msg/sec |~3843|~5865|
> 
> 
> The results I'm obtaining here are not so surprising since all normal
> transfers are taking the lock in read mode, so there's no contention.
> I didn't measure the impact on performances when there's one
> maintenance operation taking the lock in write mode and several normal
> transfers waiting for this lock, but really, maintenance operations are
> infrequent, and that's not where performance matters in our use case.
> 
> I also did the same test with only one device doing transfers on the
> bus, and this time the mutex wins, but there's not a huge difference.
> 
>   |mutex|rwsem|
> ---
> total |67116|66561|
> msg/sec |~6712|~6656|
> 
> Let me know if you want more information on the test procedure.

Nice, thanks for testing, so it is a real win here, good!

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

[PATCH 2/3] Documentation: Add Luis R. Rodriguez to list of enforcement statement endorsers

[Greg Kroah-Hartman]

From: "Luis R. Rodriguez" <mcg...@kernel.org>

Add my name to the list.

Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 Documentation/process/kernel-enforcement-statement.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/process/kernel-enforcement-statement.rst 
b/Documentation/process/kernel-enforcement-statement.rst
index 99a9135a965c..417cb975992f 100644
--- a/Documentation/process/kernel-enforcement-statement.rst
+++ b/Documentation/process/kernel-enforcement-statement.rst
@@ -145,6 +145,7 @@ we might work for today, have in the past, or will in the 
future.
   - Linus Torvalds
   - Thierry Reding
   - Rik van Riel
+  - Luis R. Rodriguez
   - Geert Uytterhoeven (Glider bvba)
   - Eduardo Valentin (Amazon.com)
   - Daniel Vetter
-- 
2.15.1

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

[PATCH 1/3] Documentation: Add Kees Cook to list of enforcement statement endorsers

[Greg Kroah-Hartman]

From: Kees Cook <keesc...@chromium.org>

Add my name to the list.

Signed-off-by: Kees Cook <keesc...@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 Documentation/process/kernel-enforcement-statement.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/process/kernel-enforcement-statement.rst 
b/Documentation/process/kernel-enforcement-statement.rst
index bfa6a78103d8..99a9135a965c 100644
--- a/Documentation/process/kernel-enforcement-statement.rst
+++ b/Documentation/process/kernel-enforcement-statement.rst
@@ -68,6 +68,7 @@ we might work for today, have in the past, or will in the 
future.
   - Paul Burton
   - Javier Martinez Canillas
   - Rob Clark
+  - Kees Cook (Google)
   - Jonathan Corbet
   - Dennis Dalessandro
   - Vivien Didelot (Savoir-faire Linux)
-- 
2.15.1

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

[PATCH 3/3] Documentation: Add myself to the enforcement statement list

[Greg Kroah-Hartman]

From: David Sterba <dste...@suse.com>

Signed-off-by: David Sterba <dste...@suse.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 Documentation/process/kernel-enforcement-statement.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/process/kernel-enforcement-statement.rst 
b/Documentation/process/kernel-enforcement-statement.rst
index 417cb975992f..6816c12d6956 100644
--- a/Documentation/process/kernel-enforcement-statement.rst
+++ b/Documentation/process/kernel-enforcement-statement.rst
@@ -138,6 +138,7 @@ we might work for today, have in the past, or will in the 
future.
   - Anna Schumaker
   - Jes Sorensen
   - K.Y. Srinivasan
+  - David Sterba (SUSE)
   - Heiko Stuebner
   - Jiri Kosina (SUSE)
   - Willy Tarreau
-- 
2.15.1

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

[PATCH 0/3] Documentation: more names to the enforcement statement

[Greg Kroah-Hartman]

Hi Jon,

Here are 3 patches for the kernel-enforcement-statement file that came
in after the file was originally added to the kernel tree.

thanks,

greg k-h

David Sterba (1):
  Documentation: Add myself to the enforcement statement list

Kees Cook (1):
  Documentation: Add Kees Cook to list of enforcement statement
endorsers

Luis R. Rodriguez (1):
  Documentation: Add Luis R. Rodriguez to list of enforcement statement
endorsers

 Documentation/process/kernel-enforcement-statement.rst | 3 +++
 1 file changed, 3 insertions(+)

-- 
2.15.1

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

Re: [PATCH v10 08/13] regmap: add SLIMbus support

[Greg Kroah-Hartman]

On Mon, Dec 11, 2017 at 11:43:02PM +, srinivas.kandaga...@linaro.org wrote:
> From: Srinivas Kandagatla 
> 
> This patch adds support to read/write SLIMbus value elements.
> Currently it only supports byte read/write. Adding this support in
> regmap would give codec drivers more flexibility when there are more
> than 2 control interfaces like SLIMbus, i2c.
> 
> Without this patch each codec driver has to directly call SLIMbus value
> element apis, and this could would get messy once we want to add i2c
> interface to it.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---
>  drivers/base/regmap/Kconfig  |  4 ++
>  drivers/base/regmap/Makefile |  1 +
>  drivers/base/regmap/regmap-slimbus.c | 80 
> 
>  include/linux/regmap.h   | 18 
>  4 files changed, 103 insertions(+)
>  create mode 100644 drivers/base/regmap/regmap-slimbus.c

Mark, can I get an Ack for this patch so I can take it through my tree
with the other patches in this series?

thanks,

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

Re: [PATCH v10 00/13] Introduce framework for SLIMbus device driver

[Greg Kroah-Hartman]

On Mon, Dec 11, 2017 at 11:42:54PM +, srinivas.kandaga...@linaro.org wrote:
> From: Srinivas Kandagatla 
> 
> SLIMbus (Serial Low Power Interchip Media Bus) is a specification
> developed by MIPI (Mobile Industry Processor Interface) alliance.
> SLIMbus is a 2-wire implementation, which is used to communicate with
> peripheral components like audio-codec.
> SLIMbus uses Time-Division-Multiplexing to accommodate multiple data
> channels, and control channel. Control channel has messages to do
> device-enumeration, messages to send/receive control-data to/from
> SLIMbus devices, messages for port/channel management, and messages to
> do bandwidth allocation.
> Framework is introduced to support  multiple instances of the bus
> (1 controller per bus), and multiple slave devices per controller.
> SPI and I2C frameworks, and comments from last time when I submitted
> the patches were referred-to while working on this framework.
> 
> These patchsets introduce device-management, OF helpers, and messaging
> APIs, controller driver for Qualcomm's SLIMbus controller, and
> clock-pause feature for entering/exiting low-power mode for SLIMbus.
> Framework patches to do channel, port and bandwidth
> management are work-in-progress and will be sent out once these
> initial patches are accepted.
> 
> These patchsets were tested on IFC6410 board with Qualcomm APQ8064
> processor using the controller driver, and a WCD9310 codec.
> 
> v9: https://lkml.org/lkml/2017/12/7/289
> 
> Changes from v9 to v10:
> * Added kernel-doc reference into slimbus driver api doc suggested by
>  Jonathan Corbet

These all look good to me.  I can take this through my tree if I get the
ack from Mark for the regmap changes.

thanks,

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

[PATCH 4.9 102/109] dma-buf: Update kerneldoc for sync_file_create

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Daniel Vetter <daniel.vet...@ffwll.ch>

commit 24a367348a017555f982a9ee137070a7a821fa97 upstream.

This was missed when adding a dma_fence_get call. While at it also
remove the kerneldoc for the static inline helper - no point
documenting internals down to every detail.

Fixes: 30cd85dd6edc ("dma-buf/sync_file: hold reference to fence when creating 
sync_file")
Cc: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
Cc: Sean Paul <seanp...@chromium.org>
Cc: linux-doc@vger.kernel.org
Cc: Jonathan Corbet <cor...@lwn.net>
Cc: Sumit Semwal <sumit.sem...@linaro.org>
Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
Reviewed-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
Signed-off-by: Sumit Semwal <sumit.sem...@linaro.org>
Link: 
http://patchwork.freedesktop.org/patch/msgid/20161209185309.1682-3-daniel.vet...@ffwll.ch
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
 drivers/dma-buf/sync_file.c |   14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -67,9 +67,10 @@ static void fence_check_cb_func(struct f
  * sync_file_create() - creates a sync file
  * @fence: fence to add to the sync_fence
  *
- * Creates a sync_file containg @fence. Once this is called, the sync_file
- * takes ownership of @fence. The sync_file can be released with
- * fput(sync_file->file). Returns the sync_file or NULL in case of error.
+ * Creates a sync_file containg @fence. This function acquires and additional
+ * reference of @fence for the newly-created _file, if it succeeds. The
+ * sync_file can be released with fput(sync_file->file). Returns the
+ * sync_file or NULL in case of error.
  */
 struct sync_file *sync_file_create(struct fence *fence)
 {
@@ -90,13 +91,6 @@ struct sync_file *sync_file_create(struc
 }
 EXPORT_SYMBOL(sync_file_create);
 
-/**
- * sync_file_fdget() - get a sync_file from an fd
- * @fd:fd referencing a fence
- *
- * Ensures @fd references a valid sync_file, increments the refcount of the
- * backing file. Returns the sync_file or NULL in case of error.
- */
 static struct sync_file *sync_file_fdget(int fd)
 {
struct file *file = fget(fd);


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

Re: [PATCH v2] doc: add maintainer book

[Greg Kroah-Hartman]

On Sat, Nov 25, 2017 at 07:22:36PM +1100, Tobin C. Harding wrote:
> On Sat, Nov 25, 2017 at 08:56:23AM +0100, Greg Kroah-Hartman wrote:
> > On Sat, Nov 25, 2017 at 08:44:19AM +1100, Tobin C. Harding wrote:
> > > There is currently very little documentation in the kernel on maintainer
> > > level tasks. In particular there are no documents on creating pull
> > > requests to submit to Linus.
> > > 
> > > Quoting Greg Kroah-Hartman on LKML:
> > > 
> > > Anyway, this actually came up at the kernel summit / maintainer
> > > meeting a few weeks ago, in that "how do I make a
> > > good pull request to Linus" is something we need to document.
> > > 
> > > Here's what I do, and it seems to work well, so maybe we should turn
> > > it into the start of the documentation for how to do it.
> > > 
> > > (quote references: kernel summit, Europe 2017)
> > > 
> > > Create a new kernel documentation book 'how to be a maintainer'
> > > (suggested by Jonathan Corbet). Add chapters on 'configuring git' and
> > > 'creating a pull request'.
> > > 
> > > Most of the content was written by Linus Torvalds and Greg Kroah-Hartman
> > > in discussion on LKML. This is stated at the start of one of the
> > > chapters and the original email thread is referenced in
> > > 'pull-requests.rst'.
> > > 
> > > Signed-off-by: Tobin C. Harding <m...@tobin.cc>
> > > ---
> > 
> > You dropped my reviewed-by :(
> 
> Oh, I didn't realize I was able to keep it between versions. I realize
> this was a reasonably trivial change but in general how much change is
> ok while keeping the reviewed-by? Who's call is it, the original
> author, the reviewed-by dev or the maintainer?

Use your judgement, usually for tiny changes it's good to keep it so
people don't have to keep reviewing it and adding it again.

thanks,

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

Re: [PATCH v2] doc: add maintainer book

[Greg Kroah-Hartman]

On Sat, Nov 25, 2017 at 08:44:19AM +1100, Tobin C. Harding wrote:
> There is currently very little documentation in the kernel on maintainer
> level tasks. In particular there are no documents on creating pull
> requests to submit to Linus.
> 
> Quoting Greg Kroah-Hartman on LKML:
> 
> Anyway, this actually came up at the kernel summit / maintainer
> meeting a few weeks ago, in that "how do I make a
> good pull request to Linus" is something we need to document.
> 
> Here's what I do, and it seems to work well, so maybe we should turn
> it into the start of the documentation for how to do it.
> 
> (quote references: kernel summit, Europe 2017)
> 
> Create a new kernel documentation book 'how to be a maintainer'
> (suggested by Jonathan Corbet). Add chapters on 'configuring git' and
> 'creating a pull request'.
> 
> Most of the content was written by Linus Torvalds and Greg Kroah-Hartman
> in discussion on LKML. This is stated at the start of one of the
> chapters and the original email thread is referenced in
> 'pull-requests.rst'.
> 
> Signed-off-by: Tobin C. Harding <m...@tobin.cc>
> ---

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

Re: [RFC] doc: add maintainer book

[Greg Kroah-Hartman]

On Wed, Nov 22, 2017 at 09:39:39AM +1100, Tobin C. Harding wrote:
> There is currently very little documentation in the kernel on maintainer
> level tasks. In particular there are no documents on creating pull
> requests to submit to Linus.
> 
> Quoting Greg Kroah-Hartman on LKML:
> 
> Anyway, this actually came up at the kernel summit / maintainer
> meeting a few weeks ago, in that "how do I make a
> good pull request to Linus" is something we need to document.
> 
> Here's what I do, and it seems to work well, so maybe we should turn
> it into the start of the documentation for how to do it.
> 
> (quote references: kernel summit, Europe 2017)
> 
> Create a new kernel documentation book 'how to be a maintainer'
> (suggested by Jonathan Corbet). Add chapters on 'configuring git' and
> 'creating a pull request'.
> 
> Most of the content was written by Linus Torvalds and Greg Kroah-Hartman
> in discussion on LKML. This is stated at the start of one of the
> chapters and the original email thread is referenced in
> 'pull-requests.rst'.
> 
> Signed-off-by: Tobin C. Harding <m...@tobin.cc>
> ---
> 
> Linus and Greg are CC'd because they are quoted heavily in the document.
> 
> Greg,
> 
> This is my second attempt at this but still it reads as if I am saying things
> that actually you said. I feel this is in the spirit of your original message
> but I would still like you to okay it please. Any suggestions (from anyone) 
> on a
> better way to word, or structure, the document most welcome.

This looks great to me, thanks for starting it out.  It can be added to
more later (like the 'how to set up git' section), but that is easier to
add to an existing document rather than just starting with none.

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Documentation/process: add Co-Developed-by: tag for patches with multiple authors

[Greg Kroah-Hartman]

Sometimes a single patch is the result of multiple authors.  As git only
can have one "author" of a patch, it is still good to properly give
credit to the other developers of a commit.  To address this, document
the "Co-Developed-by:" tag which can be used to show other authors of
the patch.

Note, these other authors must also provide a Signed-off-by: tag as it
is their work that is being submitted here.

Reported-by: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>


diff --git a/Documentation/process/5.Posting.rst 
b/Documentation/process/5.Posting.rst
index 1b7728b19ea7..645fa9c7388a 100644
--- a/Documentation/process/5.Posting.rst
+++ b/Documentation/process/5.Posting.rst
@@ -213,6 +213,11 @@ The tags in common use are:
which can be found in Documentation/process/submitting-patches.rst.  Code 
without a
proper signoff cannot be merged into the mainline.
 
+ - Co-Developed-by: states that the patch was also created by another developer
+   along with the original author.  This is useful at times when multiple
+   people work on a single patch.  Note, this person also needs to have a
+   Signed-off-by: line in the patch as well.
+
  - Acked-by: indicates an agreement by another developer (often a
maintainer of the relevant code) that the patch is appropriate for
inclusion into the kernel.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git pull

[Greg Kroah-Hartman]

On Tue, Nov 14, 2017 at 01:00:14PM +0100, Ulf Hansson wrote:
> [...]
> 
> >
> > An example pull request of mine might look like:
> > Char/Misc patches for 4.15-rc1
> >
> > Here is the big char/misc patch set for the 4.15-rc1 merge
> > window.  Contained in here is the normal set of new functions
> > added to all of these crazy drivers, as well as the following
> > brand new subsystems:
> > - time_travel_controller: Finally a set of drivers for
> >   the latest time travel bus architecture that provides
> >   i/o to the CPU before it asked for it, allowing
> >   uninterrupted processing
> > - relativity_shifters: due to the affect that the
> >   time_travel_controllers have on the overall system,
> >   there was a need for a new set of relativity shifter
> >   drivers to accommodate the newly formed black holes
> >   that would threaten to suck CPUs into them.  This
> >   subsystem handles this in a way to successfully
> >   neutralize the problems.  There is a Kconfig option to
> >   force these to be enabled when needed, so problems
> >   should not occur.
> >
> > All of these patches have been successfully tested in the latest
> > linux-next releases, and the original problems that it found
> > have all been resolved (apologies to anyone living near Canberra
> > for the lack of the Kconfig options in the earlier versions of
> > the linux-next tree creations.)
> >
> > Signed-off-by: Your-name-here 
> >
> >
> > The tag message format is just like a git commit id.  One line at the
> > top for a "summary subject" and be sure to sign-off at the bottom.
> 
> I don't add my s-o-b to signed tags for pull requests, but perhaps I should.
> 
> However, I think most maintainers don't use it, and neither does it
> seems like Linus is preserving the tag when he does the pull.

The text of the tag is in the merge commit, but you are right, the
signed-off-by doesn't seem to be in the merge commit, I guess Linus's
workflow removes them.  I know I keep them in there if present for pull
requests that people send to me.

thanks,

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

Re: git pull

[Greg Kroah-Hartman]

Adding lkml and linux-doc mailing lists...

On Tue, Nov 14, 2017 at 10:11:55AM +1100, Tobin C. Harding wrote:
> Hi Greg,
> 
> This is totally asking a favour, feel free to ignore. How do you format
> your [GIT PULL] emails to Linus? Do you create a tag and then run a git
> command to get the email?
> 
> I tried to do it manually and failed pretty hard (as you no doubt will
> notice on LKML).

Well, I think you got it right the third time, so nice job :)

Anyway, this actually came up at the kernel summit / maintainer meeting
a few weeks ago, in that "how do I make a good pull request to Linus" is
something we need to document.

Here's what I do, and it seems to work well, so maybe we should turn it
into the start of the documentation for how to do it.

---

To start with, put your changes on a branch, hopefully one named in a
semi-useful way (I use 'char-misc-next' for my char/misc driver patches
to be merged into linux-next).  That is the branch you wish to tag and
have Linus pull from.

Name the tag with something useful that you can understand if you run
across it in a few weeks, and something that will be "unique".
Continuing the example of my char-misc tree, for the patches to be sent
to Linus for the 4.15-rc1 merge window, I would name the tag
'char-misc-4.15-rc1':
git tag -u KEY_ID -s char-misc-4.15-rc1 char-misc-next

that will create a signed tag called 'char-misc-4.15-rc1' based on the
last commit in the char-misc-next branch, and sign it with my gpg key
KEY_ID (replace KEY_ID with your own gpg key id.)

When you run the above command, git will drop you into an editor and ask
you to describe the tag.  In this case, you are describing a pull
request, so outline what is contained here, why it should be merged, and
what, if any, testing has happened to it.  All of this information will
end up in the tag itself, and then in the merge commit that Linus makes,
so write it up well, as it will be in the kernel tree for forever.

An example pull request of mine might look like:
Char/Misc patches for 4.15-rc1

Here is the big char/misc patch set for the 4.15-rc1 merge
window.  Contained in here is the normal set of new functions
added to all of these crazy drivers, as well as the following
brand new subsystems:
- time_travel_controller: Finally a set of drivers for
  the latest time travel bus architecture that provides
  i/o to the CPU before it asked for it, allowing
  uninterrupted processing
- relativity_shifters: due to the affect that the
  time_travel_controllers have on the overall system,
  there was a need for a new set of relativity shifter
  drivers to accommodate the newly formed black holes
  that would threaten to suck CPUs into them.  This
  subsystem handles this in a way to successfully
  neutralize the problems.  There is a Kconfig option to
  force these to be enabled when needed, so problems
  should not occur.

All of these patches have been successfully tested in the latest
linux-next releases, and the original problems that it found
have all been resolved (apologies to anyone living near Canberra
for the lack of the Kconfig options in the earlier versions of
the linux-next tree creations.)

Signed-off-by: Your-name-here 


The tag message format is just like a git commit id.  One line at the
top for a "summary subject" and be sure to sign-off at the bottom.

Now that you have a local signed tag, you need to push it up to where it
can be retrieved by others:
git push origin char-misc-4.15-rc1
pushes the char-misc-4.15-rc1 tag to where the 'origin' repo is located.

The last thing to do is create the pull request message.  Git handily
will do this for you with the 'git request-pull' command, but it needs a
bit of help determining what you want to pull, and what to base the pull
against (to show the correct changes to be pulled and the diffstat.)

I use the following command to generate a pull request:
git request-pull master 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ 
char-misc-4.15-rc1

This is asking git to compare the difference from the
'char-misc-4.15-rc1' tag location, to the head of the 'master' branch
(which in my case points to the last location in Linus's tree that I
diverged from, usually a -rc release) and to use the git:// protocol to
pull from.  If you wish to use https://, that can be used here instead
as well (but note that some people behind firewalls will have problems
with https git pulls).

If the char-misc-4.15-rc1 tag is not present in the repo that I am
asking to be pulled from, git will complain saying it is not there, a
handy way to remember to actually push it to a public location.

The 

Re: [PATCH] Documentation: support kernel enforcement

[Greg Kroah-Hartman]

On Wed, Oct 25, 2017 at 03:27:07PM +0200, Jarkko Sakkinen wrote:
> I'm sorry that I forgot to add my name on time.
> 
> Signed-off-by: Jarkko Sakkinen 
> ---
>  Documentation/process/kernel-enforcement-statement.rst | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/process/kernel-enforcement-statement.rst 
> b/Documentation/process/kernel-enforcement-statement.rst
> index 1e23d4227337..f5a91b68a45c 100644
> --- a/Documentation/process/kernel-enforcement-statement.rst
> +++ b/Documentation/process/kernel-enforcement-statement.rst
> @@ -145,3 +145,4 @@ we might work for today, have in the past, or will in the 
> future.
>- Masahiro Yamada
>- Wei Yongjun
>- Lv Zheng
> +  - Jarkko Sakkinen

Please do so in alphabetical order, sorted by your last name.

thanks,

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

Re: [Update][PATCH v2 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags

[Greg Kroah-Hartman]

On Fri, Oct 20, 2017 at 01:11:22PM +0200, Rafael J. Wysocki wrote:
> On Thursday, October 19, 2017 9:33:15 AM CEST Greg Kroah-Hartman wrote:
> > On Thu, Oct 19, 2017 at 01:17:31AM +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> > > 
> > > The motivation for this change is to provide a way to work around
> > > a problem with the direct-complete mechanism used for avoiding
> > > system suspend/resume handling for devices in runtime suspend.
> > > 
> > > The problem is that some middle layer code (the PCI bus type and
> > > the ACPI PM domain in particular) returns positive values from its
> > > system suspend ->prepare callbacks regardless of whether the driver's
> > > ->prepare returns a positive value or 0, which effectively prevents
> > > drivers from being able to control the direct-complete feature.
> > > Some drivers need that control, however, and the PCI bus type has
> > > grown its own flag to deal with this issue, but since it is not
> > > limited to PCI, it is better to address it by adding driver flags at
> > > the core level.
> > > 
> > > To that end, add a driver_flags field to struct dev_pm_info for flags
> > > that can be set by device drivers at the probe time to inform the PM
> > > core and/or bus types, PM domains and so on on the capabilities and/or
> > > preferences of device drivers.  Also add two static inline helpers
> > > for setting that field and testing it against a given set of flags
> > > and make the driver core clear it automatically on driver remove
> > > and probe failures.
> > > 
> > > Define and document two PM driver flags related to the direct-
> > > complete feature: NEVER_SKIP and SMART_PREPARE that can be used,
> > > respectively, to indicate to the PM core that the direct-complete
> > > mechanism should never be used for the device and to inform the
> > > middle layer code (bus types, PM domains etc) that it can only
> > > request the PM core to use the direct-complete mechanism for
> > > the device (by returning a positive value from its ->prepare
> > > callback) if it also has been requested by the driver.
> > > 
> > > While at it, make the core check pm_runtime_suspended() when
> > > setting power.direct_complete so that it doesn't need to be
> > > checked by ->prepare callbacks.
> > > 
> > > Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> > 
> > Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> 
> Thanks!
> 
> Does it also apply to the other patches in the series?
> 
> I'd like to queue up the core patches for 4.15 as they are specifically
> designed to only affect the drivers that actually set the flags, so there
> shouldn't be any regression resulting from them, and I'd like to be
> able to start using the flags in drivers going forward.

Yes, sorry, I thought I acked them, but you are right, I didn't:

Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

for all of them please.

thanks,

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

Re: [Update][PATCH v2 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags

[Greg Kroah-Hartman]

On Thu, Oct 19, 2017 at 01:17:31AM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> 
> The motivation for this change is to provide a way to work around
> a problem with the direct-complete mechanism used for avoiding
> system suspend/resume handling for devices in runtime suspend.
> 
> The problem is that some middle layer code (the PCI bus type and
> the ACPI PM domain in particular) returns positive values from its
> system suspend ->prepare callbacks regardless of whether the driver's
> ->prepare returns a positive value or 0, which effectively prevents
> drivers from being able to control the direct-complete feature.
> Some drivers need that control, however, and the PCI bus type has
> grown its own flag to deal with this issue, but since it is not
> limited to PCI, it is better to address it by adding driver flags at
> the core level.
> 
> To that end, add a driver_flags field to struct dev_pm_info for flags
> that can be set by device drivers at the probe time to inform the PM
> core and/or bus types, PM domains and so on on the capabilities and/or
> preferences of device drivers.  Also add two static inline helpers
> for setting that field and testing it against a given set of flags
> and make the driver core clear it automatically on driver remove
> and probe failures.
> 
> Define and document two PM driver flags related to the direct-
> complete feature: NEVER_SKIP and SMART_PREPARE that can be used,
> respectively, to indicate to the PM core that the direct-complete
> mechanism should never be used for the device and to inform the
> middle layer code (bus types, PM domains etc) that it can only
> request the PM core to use the direct-complete mechanism for
> the device (by returning a positive value from its ->prepare
> callback) if it also has been requested by the driver.
> 
> While at it, make the core check pm_runtime_suspended() when
> setting power.direct_complete so that it doesn't need to be
> checked by ->prepare callbacks.
> 
> Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] Documentation: update kernel enforcement support list

[Greg Kroah-Hartman]

On Tue, Oct 17, 2017 at 08:06:53AM -0700, Eduardo Valentin wrote:
> Adding myself to the list as I missed the window to be in the original patch.
> 
> Cc: Jonathan Corbet 
> Cc: Bart Van Assche 
> Cc: Namhyung Kim 
> Cc: Olof Johansson 
> Cc: Juergen Gross 
> Cc: Javier Martinez Canillas 
> Signed-off-by: Eduardo Valentin 
> ---
>  Documentation/process/kernel-enforcement-statement.rst | 1 +
>  1 file changed, 1 insertion(+)

Thanks for this, now applied to my tree.

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

Re: [PATCH 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags

[Greg Kroah-Hartman]

On Tue, Oct 17, 2017 at 12:07:37AM +0200, Rafael J. Wysocki wrote:
> On Monday, October 16, 2017 8:31:22 AM CEST Greg Kroah-Hartman wrote:
> > On Mon, Oct 16, 2017 at 03:29:02AM +0200, Rafael J. Wysocki wrote:
> > > +static inline void dev_pm_set_driver_flags(struct device *dev, unsigned 
> > > int flags)
> > > +{
> > > + dev->power.driver_flags = flags;
> > > +}
> > 
> > Should this function just set the specific bit?  Or is it going to be ok
> > to set the whole value, meaning you aren't going to care about turning
> > on and off specific flags over the lifetime of the driver/device, you
> > are just going to set them once and then just test them as needed?
> 
> The idea is to set them once and they should not be touched again until
> the driver (or device) goes away, so that would be the whole value at once
> (and one of the i2c-designware-platdrv patches actually sets multiple flags
> in one go).

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

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

[Greg Kroah-Hartman]

On Mon, Oct 16, 2017 at 03:12:35AM +0200, Rafael J. Wysocki wrote:
> Hi All,
> 
> Well, this took more time than expected, as I tried to cover everything I had
> in mind regarding PM flags for drivers.
> 
> This work was triggered by attempts to fix and optimize PM in the
> i2c-designware-platdev driver that ended up with adding a couple of
> flags to the driver's internal data structures for the tracking of
> device state (https://marc.info/?l=linux-acpi=150629646805636=2).
> That approach is sort of suboptimal, though, because other drivers will
> probably want to do similar things and if all of them need to use internal
> flags for that, quite a bit of code duplication may ensue at least.
> 
> That can be avoided in a couple of ways and one of them is to provide a means
> for drivers to tell the core what to do and to make the core take care of it
> if told to do so.  Hence, the idea to use driver flags for system-wide PM
> that was briefly discussed during the LPC in LA last month.
> 
> One of the flags considered at that time was to possibly cause the core
> to reuse the runtime PM callback path of a device for system suspend/resume.
> Admittedly, that idea didn't look too bad to me until I had started to try to
> implement it and I got to the PCI bus type's hibernation callbacks.  Then, I
> moved the patch I was working on to /dev/null right away.  I mean it.
> 
> No, this is not going to happen.  No way.
> 
> Moreover, that experience made me realize that the whole *idea* of using the
> runtime PM callback path for system-wide PM was actually totally bogus (sorry
> Ulf).
> 
> The whole point of having different callbacks pointers for different types of
> device transitions is because it may be necessary to do different things in
> those callbacks in general.  Now, if you consider runtime PM and system
> suspend/resume *only* and from a driver perspective, then yes, in some cases
> the same pair of callback routines may be used for all suspend-like and
> resume-like transitions of the device, but if you add hibernation to the mix,
> then it is not so clear any more unless the callbacks don't actually do any
> power management at all, but simply quiesce the device's activity and then
> activate it again.  Namely, changing power states of devices during the
> hibernation's "freeze" and "thaw" transitions rarely makes sense at all and
> the "restore" transition needs to be able to cope with uninitialized devices
> (in fact, it should be prepared to cope with devices in *any* state), so
> runtime PM is hardly suitable for them.  Still, if a *driver* choses to not
> do any real PM in its PM callbacks and leaves that to a middle layer (quite
> a few drivers do that), then it possibly can use one pair of callbacks in all
> cases and be happy, but middle layers pretty much have to use different
> callback routines for different transitions.
> 
> If you are a middle layer, your role is basically to do PM for a certain
> group of devices.  Thus you cannot really do the same in ->suspend or
> ->suspend_early and in ->runtime_suspend (because the former generally need to
> take device_may_wakeup() into account and the latter doesn't) and you 
> shouldn't
> really do the same in ->suspend and ->freeze (becuase the latter shouldn't
> change the device's power state) and so on.  To put it bluntly, trying
> to use the ->runtime_suspend callback of a middle layer for anything other
> than runtime suspend is complete and utter nonsense.  At the same time, the
> ->runtime_resume callback of a middle layer may be reused to some extent,
> but even that doesn't cover the "thaw" transitions during hibernation.
> 
> What can work (and this is the only strategy that can work AFAICS) is to
> point different callback pointers *in* *a* *driver* to the same routine
> if the driver wants to reuse that code.  That actually will work for PCI
> and USB drivers today, at least most of the time, but unfortunately there
> are problems with it for, say, platform devices.
> 
> The first problem is the requirement to track the status of the device
> (suspended vs not suspended) in the callbacks, because the system-wide PM
> code in the PM core doesn't do that.  The runtime PM framework does it, so
> this means adding some extra code which isn't necessary for runtime PM to
> the callback routines and that is not particularly nice.
> 
> The second problem is that, if the driver wants to do anything in its
> ->suspend callback, it generally has to prevent runtime suspend of the
> device from taking place in parallel with that, which is quite cumbersome.
> Usually, that is taken care of by resuming the device from runtime suspend
> upfront, but generally doing that is wasteful (there may be no real need to
> resume the device except for the fact that the code is designed this way).
> 
> On top of the above, there are optimizations to be made, like leaving certain
> devices in suspend after system resume to avoid wasting time on waiting for
> 

Re: [PATCH 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags

[Greg Kroah-Hartman]

On Mon, Oct 16, 2017 at 03:29:02AM +0200, Rafael J. Wysocki wrote:
> +static inline void dev_pm_set_driver_flags(struct device *dev, unsigned int 
> flags)
> +{
> + dev->power.driver_flags = flags;
> +}

Should this function just set the specific bit?  Or is it going to be ok
to set the whole value, meaning you aren't going to care about turning
on and off specific flags over the lifetime of the driver/device, you
are just going to set them once and then just test them as needed?

thanks,

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

Re: [PATCH 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags

[Greg Kroah-Hartman]

On Mon, Oct 16, 2017 at 03:29:02AM +0200, Rafael J. Wysocki wrote:
>  struct dev_pm_info {
>   pm_message_tpower_state;
>   unsigned intcan_wakeup:1;
> @@ -561,6 +580,7 @@ struct dev_pm_info {
>   boolis_late_suspended:1;
>   boolearly_init:1;   /* Owned by the PM core */
>   booldirect_complete:1;  /* Owned by the PM core 
> */
> + unsigned intdriver_flags;

Minor nit, u32 or u64?

thanks,

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

[PATCH] Documentation: add Kernel Driver Statement to the kernel

[Greg Kroah-Hartman]

Way back in 2008 we didn't have "robust" in-kernel documentation system,
so the idea of putting something like the kernel driver statement in the
kernel tree wasn't even imagined.  But now that has changed, so add the
old document to the kernel source itself to allow for us to properly
reference it in one canonical place (as the LF wiki keeps moving things
around.)

This also will allow people to add their names to it, as I seem to have
lost the ability to do that by not knowing how to edit things on the
original document.

Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---

Jon, if this isn't the correct place to put the document, I'd be glad to
move it elsewhere, I just picked the first place that it seemed to fit
into.


 Documentation/process/index.rst   |   1 +
 Documentation/process/kernel-driver-statement.rst | 199 ++
 2 files changed, 200 insertions(+)
 create mode 100644 Documentation/process/kernel-driver-statement.rst

diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
index 82fc399fcd33..68454319f006 100644
--- a/Documentation/process/index.rst
+++ b/Documentation/process/index.rst
@@ -25,6 +25,7 @@ Below are the essential guides that every developer should 
read.
submitting-patches
coding-style
email-clients
+   kernel-driver-statement
 
 Other guides to the community that are of interest to most developers are: 
 
diff --git a/Documentation/process/kernel-driver-statement.rst 
b/Documentation/process/kernel-driver-statement.rst
new file mode 100644
index ..60d9d868f300
--- /dev/null
+++ b/Documentation/process/kernel-driver-statement.rst
@@ -0,0 +1,199 @@
+Kernel Driver Statement
+---
+
+Position Statement on Linux Kernel Modules
+==
+
+
+We, the undersigned Linux kernel developers, consider any closed-source
+Linux kernel module or driver to be harmful and undesirable. We have
+repeatedly found them to be detrimental to Linux users, businesses, and
+the greater Linux ecosystem. Such modules negate the openness,
+stability, flexibility, and maintainability of the Linux development
+model and shut their users off from the expertise of the Linux
+community. Vendors that provide closed-source kernel modules force their
+customers to give up key Linux advantages or choose new vendors.
+Therefore, in order to take full advantage of the cost savings and
+shared support benefits open source has to offer, we urge vendors to
+adopt a policy of supporting their customers on Linux with open-source
+kernel code.
+
+We speak only for ourselves, and not for any company we might work for
+today, have in the past, or will in the future.
+
+ - Dave Airlie
+ - Nick Andrew
+ - Jens Axboe
+ - Ralf Baechle
+ - Felipe Balbi
+ - Ohad Ben-Cohen
+ - Muli Ben-Yehuda
+ - Jiri Benc
+ - Arnd Bergmann
+ - Thomas Bogendoerfer
+ - Vitaly Bordug
+ - James Bottomley
+ - Josh Boyer
+ - Neil Brown
+ - Mark Brown
+ - David Brownell
+ - Michael Buesch
+ - Franck Bui-Huu
+ - Adrian Bunk
+ - François Cami
+ - Ralph Campbell
+ - Luiz Fernando N. Capitulino
+ - Mauro Carvalho Chehab
+ - Denis Cheng
+ - Jonathan Corbet
+ - Glauber Costa
+ - Alan Cox
+ - Magnus Damm
+ - Ahmed S. Darwish
+ - Robert P. J. Day
+ - Hans de Goede
+ - Arnaldo Carvalho de Melo
+ - Helge Deller
+ - Jean Delvare
+ - Mathieu Desnoyers
+ - Sven-Thorsten Dietrich
+ - Alexey Dobriyan
+ - Daniel Drake
+ - Alex Dubov
+ - Randy Dunlap
+ - Michael Ellerman
+ - Pekka Enberg
+ - Jan Engelhardt
+ - Mark Fasheh
+ - J. Bruce Fields
+ - Larry Finger
+ - Jeremy Fitzhardinge
+ - Mike Frysinger
+ - Kumar Gala
+ - Robin Getz
+ - Liam Girdwood
+ - Jan-Benedict Glaw
+ - Thomas Gleixner
+ - Brice Goglin
+ - Cyrill Gorcunov
+ - Andy Gospodarek
+ - Thomas Graf
+ - Krzysztof Halasa
+ - Harvey Harrison
+ - Stephen Hemminger
+ - Michael Hennerich
+ - Tejun Heo
+ - Benjamin Herrenschmidt
+ - Kristian Høgsberg
+ - Henrique de Moraes Holschuh
+ - Marcel Holtmann
+ - Mike Isely
+ - Takashi Iwai
+ - Olof Johansson
+ - Dave Jones
+ - Jesper Juhl
+ - Matthias Kaehlcke
+ - Kenji Kaneshige
+ - Jan Kara
+ - Jeremy Kerr
+ - Russell King
+ - Olaf Kirch
+ - Roel Kluin
+ - Hans-Jürgen Koch
+ - Auke Kok
+ - Peter Korsgaard
+ - Jiri Kosina
+ - Mariusz Kozlowski
+ - Greg Kroah-Hartman
+ - Michael Krufky
+ - Aneesh Kumar
+ - Clemens Ladisch
+ - Christoph Lameter
+ - Gunnar Larisch
+ - Anders Larsen
+ - Grant Likely
+ - John W. Linville
+ - Yinghai Lu
+ - Tony Luck
+ - Pavel Machek
+ - Matt Mackall
+ - Paul Mackerras
+ - Roland McGrath
+ - Patrick McHardy
+ - Kyle McMartin
+ - Paul Menage
+ - Thierry Merle
+ - Eric Miao
+ - Akinobu Mita
+ - Ingo Molnar
+ - James Morris
+ - Andrew Morton
+ - Paul Mundt
+ - Oleg Nesterov
+ - Luca Olivetti
+ - S.Çağlar Onur
+ - Pierre Ossman
+ - Keith Owens
+ - Venkatesh Pallipadi
+ - Nick Piggin
+ - Nicolas Pitre
+ - Evgeniy Polyakov
+ - Richard Purdie
+ - Mike Rapoport
+ - Sam Ravnborg
+

Re: [PATCH V3 2/8] drivers: boot_constraint: Add boot_constraints_disable kernel parameter

[Greg Kroah-Hartman]

On Tue, Aug 29, 2017 at 12:02:41PM +0200, Viresh Kumar wrote:
> On 29-08-17, 08:37, Greg Kroah-Hartman wrote:
> > On Tue, Aug 01, 2017 at 02:53:43PM +0530, Viresh Kumar wrote:
> > > + boot_constraints_disable
> > > + Do not set any boot constraints for devices.
> > 
> > Shouldn't that be the default?  As really, that is what the situation is
> > today, why force everyone to always enable the disable value?  And
> > enabling a value to disable something is usually a sign of bad naming...
> 
> I will explain once again how it is getting used and then will do whatever you
> suggest.
> 
> - Platforms that don't need boot constraints should not enable the CONFIG in 
> the
>   first place. Though we use the same kernel image on multiple hardware types
>   many times.

Right, which means this is useless as an option, don't ever rely on it
:)

> - If a platform doesn't have a platform-specific driver that adds constraints 
> at
>   boot, then the boot constraint core wouldn't get into picture at all and it 
> is
>   as good as being disabled.

Possibly, but see above for the goal of one kernel image, many different
devices.

> - And the above boot-argument (boot_constraints_disable) is used ONLY in the
>   case where the platform driver is adding boot constraints at runtime.
> 
> So, the boot-constraints are disabled by default for everyone even if the
> configuration is enabled. And that's why I named it the way it is right now.
> 
> Do you still feel that it needs to be renamed? 

Well, negative options are ackward (although usb_disable is an
option...)  It still feels wrong, and I worry about the above
single-image goal...

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

Re: [PATCH V3 2/8] drivers: boot_constraint: Add boot_constraints_disable kernel parameter

[Greg Kroah-Hartman]

On Tue, Aug 01, 2017 at 02:53:43PM +0530, Viresh Kumar wrote:
> Users must be given an option to discard any constraints set by
> bootloaders. For example, consider that a constraint is set for the LCD
> controller's supply and the LCD driver isn't loaded by the kernel. If
> the user doesn't need to use the LCD device, then he shouldn't be forced
> to honour the constraint.
> 
> We can also think about finer control of such constraints with help of
> some sysfs files, but a kernel parameter is fine to begin with.
> 
> Tested-by: Rajendra Nayak 
> Signed-off-by: Viresh Kumar 
> ---
>  Documentation/admin-guide/kernel-parameters.txt |  3 +++
>  drivers/base/boot_constraints/core.c| 17 +
>  2 files changed, 20 insertions(+)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index d9c171ce4190..0706d1b6004d 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -426,6 +426,9 @@
>   embedded devices based on command line input.
>   See Documentation/block/cmdline-partition.txt
>  
> + boot_constraints_disable
> + Do not set any boot constraints for devices.

Shouldn't that be the default?  As really, that is what the situation is
today, why force everyone to always enable the disable value?  And
enabling a value to disable something is usually a sign of bad naming...

> +
>   boot_delay= Milliseconds to delay each printk during boot.
>   Values larger than 10 seconds (1) are changed to
>   no delay (0).
> diff --git a/drivers/base/boot_constraints/core.c 
> b/drivers/base/boot_constraints/core.c
> index 366a05d6d9ba..e0c33b2b216f 100644
> --- a/drivers/base/boot_constraints/core.c
> +++ b/drivers/base/boot_constraints/core.c
> @@ -24,6 +24,17 @@
>  static LIST_HEAD(constraint_devices);
>  static DEFINE_MUTEX(constraint_devices_mutex);
>  
> +static bool boot_constraints_disabled;

Again, this should only be an "enable" type of option, that kicks in if
you are using this type of bootloader/kernel interaction.  Don't force
someone to disable it.

thanks,

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

Re: [RFC 2/5] i3c: Add core I3C infrastructure

[Greg Kroah-Hartman]

On Tue, Aug 01, 2017 at 11:30:01PM +0200, Boris Brezillon wrote:
> > > > No release type?  Oh that's bad bad bad and implies you have never
> > > > removed a device from your system as the kernel would have complained
> > > > loudly at you.  
> > > 
> > > You got me, never tried to remove a device :-). Note that these  
> > > ->release() hooks will just be dummy ones, because right now, device  
> > > resources are freed at bus destruction time.  
> > 
> > You better not have a "dummy" release hook, do that and as per the
> > kernel documentation, I get to make fun of you in public for doing that
> > :(
> 
> I'm not afraid of admitting I don't know everything, even the
> simplest things that you consider as basics for a kernel developer. You
> can make fun of me publicly if you want but that's not helping :-P.

No, I am referring to the Documentation/kobject.txt file, where it says:
One important point cannot be overstated: every kobject must
have a release() method, and the kobject must persist (in a
consistent state) until that method is called. If these
constraints are not met, the code is flawed.  Note that the
kernel will warn you if you forget to provide a release()
method.  Do not try to get rid of this warning by providing an
"empty" release function; you will be mocked mercilessly by the
kobject maintainer if you attempt this.

Sometimes I wonder why I even write documentation...

The point is, you have to release the memory the device structure "owns"
in the release callback, if not, then the model is not correct.  That's
all, please fix up your code to do so and I will be glad to review it
again.  I'm not trying to be rude here at all, but please, at the least,
read the documentation we have already first...

thanks,

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

Re: [RFC 2/5] i3c: Add core I3C infrastructure

[Greg Kroah-Hartman]

On Tue, Aug 01, 2017 at 12:48:01PM +0200, Boris Brezillon wrote:
> > > +static DEFINE_MUTEX(i3c_core_lock);
> > > +
> > > +void i3c_bus_lock(struct i3c_bus *bus, bool exclusive)
> > > +{
> > > + if (exclusive)
> > > + down_write(>lock);
> > > + else
> > > + down_read(>lock);
> > > +}  
> > 
> > The "exclusive" flag is odd, and messy, and hard to understand, don't
> > you agree?
> 
> I could create 2 functions, one for the exclusive lock and the other
> one for the shared lock.

Or you could just use a simple mutex until you determine you really
would do better with a rw lock :)

> > And have you measured the difference in using a rw lock over
> > a normal mutex and found it to be faster?  If not, just use a normal
> > mutex, it's simpler and almost always better in the end.
> 
> I did not measure the difference, but using a standard lock means
> serializing all I3C accesses going through a given master in the core.

Which you are doing with a rw lock anyway, right?

> Note that this lock is not here to guarantee that calls to
> master->ops->xxx() are serialized (this part is left to the master
> driver), but to ensure that when a bus management operation is in
> progress (like changing the address of a device on the bus), no one can
> send I3C frames. If we don't do that, one could queue an I3C transfer,
> and by the time this transfer reach the bus, the I3C device this
> message was targeting may have a different address.

That sounds really odd.  locks should protect data, not bus access,
right?

> Unless you see a good reason to not use a R/W lock, I'd like to keep it
> this way because master IPs are likely to implement advanced queuing
> mechanism (allows one to queue new transfers even if the master is
> already busy processing other requests), and serializing things at the
> framework level will just prevent us from using this kind of
> optimization.

Unless you can prove otherwise, using a rw lock is almost always worse
than just a mutex.  And you shouldn't have a lock for bus transactions,
that's just going to be a total mess.  You could have a lock for a
single device access, but that still seems really strange, is the i3c
spec that bad?

> > > +static ssize_t hdrcap_show(struct device *dev,
> > > +struct device_attribute *da,
> > > +char *buf)
> > > +{
> > > + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> > > + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> > > + unsigned long caps = i3cdev->info.hdr_cap;
> > > + ssize_t offset = 0, ret;
> > > + int mode;
> > > +
> > > + i3c_bus_lock(bus, false);
> > > + for_each_set_bit(mode, , 8) {
> > > + if (mode >= ARRAY_SIZE(hdrcap_strings))
> > > + break;
> > > +
> > > + if (!hdrcap_strings[mode])
> > > + continue;
> > > +
> > > + ret = sprintf(buf + offset, "%s\n", hdrcap_strings[mode]);  
> > 
> > Multiple lines in a single sysfs file?  No.
> 
> Okay. Would that be okay with a different separator (like a comma)?

No, sysfs files are "one value per file", given you don't have any
documentation saying what this file is supposed to be showing, I can't
really judge the proper way for you to present it to userspace :)

> > > +static const struct attribute_group *i3c_device_groups[] = {
> > > + _device_group,
> > > + NULL,
> > > +};  
> > 
> > ATTRIBUTE_GROUPS()?
> 
> My initial plan was to have a common set of attributes that apply to
> both devices and masters, and then add specific attributes in each of
> them when they only apply to a specific device type.

That's fine, but you do know that attributes can be enabled/disabled at
device creation time with the return value of the callback is_visable(),
right?  Why not just use that here, simplifying a lot of logic?

> Just out of curiosity, what's the preferred solution when you need to
> do something like that? Should we just use ATTRIBUTE_GROUPS() and
> duplicate the entries that apply to both device types?

is_visable()?

> > No release type?  Oh that's bad bad bad and implies you have never
> > removed a device from your system as the kernel would have complained
> > loudly at you.
> 
> You got me, never tried to remove a device :-). Note that these
> ->release() hooks will just be dummy ones, because right now, device
> resources are freed at bus destruction time.

You better not have a "dummy" release hook, do that and as per the
kernel documentation, I get to make fun of you in public for doing that
:(

> Also, I see that dev->release() is called instead of
> dev->type->release() if it's not NULL [1]. what's the preferred solution
> here? Set dev->release or type->release()?

It depends on how your bus is managed, who controls the creation of the
resources, free it in the same place you create it.

thanks,

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

Re: [RFC 2/5] i3c: Add core I3C infrastructure

[Greg Kroah-Hartman]

On Mon, Jul 31, 2017 at 06:24:47PM +0200, Boris Brezillon wrote:
> Add core infrastructure to support I3C in Linux and document it.
> 
> This infrastructure is not complete yet and will be extended over
> time.
> 
> There are a few design choices that are worth mentioning because they
> impact the way I3C device drivers can interact with their devices:
> 
> - all functions used to send I3C/I2C frames must be called in
>   non-atomic context. Mainly done this way to ease implementation, but
>   this is still open to discussion. Please let me know if you think it's
>   worth considering an asynchronous model here
> - the bus element is a separate object and is not implicitly described
>   by the master (as done in I2C). The reason is that I want to be able
>   to handle multiple master connected to the same bus and visible to
>   Linux.
>   In this situation, we should only have one instance of the device and
>   not one per master, and sharing the bus object would be part of the
>   solution to gracefully handle this case.
>   I'm not sure we will ever need to deal with multiple masters
>   controlling the same bus and exposed under Linux, but separating the
>   bus and master concept is pretty easy, hence the decision to do it
>   like that.
>   The other benefit of separating the bus and master concepts is that
>   master devices appear under the bus directory in sysfs.
> - I2C backward compatibility has been designed to be transparent to I2C
>   drivers and the I2C subsystem. The I3C master just registers an I2C
>   adapter which creates a new I2C bus. I'd say that, from a
>   representation PoV it's not ideal because what should appear as a
>   single I3C bus exposing I3C and I2C devices here appears as 2
>   different busses connected to each other through the parenting (the
>   I3C master is the parent of the I2C and I3C busses).
>   On the other hand, I don't see a better solution if we want something
>   that is not invasive.
> - the whole API is exposed through a single header file (i3c.h), but I'm
>   seriously considering the option of splitting the I3C driver/user API
>   and the I3C master one, mainly to hide I3C core internals and restrict
>   what I3C users can do to a limited set of functionalities (send
>   I3C/I2C frames to a specific device and that's all).
> 
> Missing features in this preliminary version:
> - no support for IBI (In Band Interrupts). This is something I'm working
>   on, and I'm still unsure how to represent it: an irqchip or a
>   completely independent representation that would be I3C specific.
>   Right now, I'm more inclined to go for the irqchip approach, since
>   this is something people are used to deal with already.
> - no Hot Join support, which is similar to hotplug
> - no support for multi-master and the associated concepts (mastership
>   handover, support for secondary masters, ...)
> - I2C devices can only be described using DT because this is the only
>   use case I have. However, the framework can easily be extended with
>   ACPI and board info support
> - I3C slave framework. This has been completely omitted, but shouldn't
>   have a huge impact on the I3C framework because I3C slaves don't see
>   the whole bus, it's only about handling master requests and generating
>   IBIs. Some of the struct, constant and enum definitions could be
>   shared, but most of the I3C slave framework logic will be different
> 
> Signed-off-by: Boris Brezillon 
> ---
>  Documentation/i3c/conf.py   |   10 +
>  Documentation/i3c/device-driver-api.rst |7 +
>  Documentation/i3c/index.rst |9 +
>  Documentation/i3c/master-driver-api.rst |8 +
>  Documentation/i3c/protocol.rst  |  199 +
>  Documentation/index.rst |1 +
>  drivers/Kconfig |2 +
>  drivers/Makefile|2 +-
>  drivers/i3c/Kconfig |   24 +
>  drivers/i3c/Makefile|3 +
>  drivers/i3c/core.c  |  532 ++
>  drivers/i3c/device.c|  138 
>  drivers/i3c/internals.h |   45 ++
>  drivers/i3c/master.c| 1225 
> +++
>  drivers/i3c/master/Kconfig  |0
>  drivers/i3c/master/Makefile |0
>  include/linux/i3c/ccc.h |  389 ++
>  include/linux/i3c/device.h  |  212 ++
>  include/linux/i3c/master.h  |  453 
>  include/linux/mod_devicetable.h |   15 +
>  20 files changed, 3273 insertions(+), 1 deletion(-)

Any chance you can break the documentation out from this patch to make
it smaller and a bit simpler to review?

Here's a few random review comments, I have only glanced at this, not
done any real reading of this at all...

> +menu "I3C support"
> +
> +config I3C
> + tristate "I3C support"
> + ---help---
> +   

Re: [Merge tag 'pci-v4.12-changes' of git] 857f864014: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8

[Greg Kroah-Hartman]

On Tue, Jun 13, 2017 at 09:13:32PM +0200, Sven-Haegar Koch wrote:
> On Tue, 13 Jun 2017, Greg Kroah-Hartman wrote:
> 
> > On Tue, Jun 13, 2017 at 10:25:40AM -0600, Logan Gunthorpe wrote:
> > > 
> > > On 12/06/17 10:35 PM, Greg Kroah-Hartman wrote:
> > > > Or better yet, just turn all char major allocations into dynamic, which
> > > > would be really good for test systems.  I thought someone proposed
> > > > patches for that a long time ago, but I can't find them anymore.  That
> > > > would be the simplest solution here.
> > > 
> > > Would people not complain about that? I would not be surprised if some
> > > crazy application is using hard coded major numbers in userspace. So
> > > such a change could potentially break userspace...
> > 
> > For char devices, I doubt it, but we can't take the chance, which is why
> > you make it an option.  Then, it's enabled for 'allmodconfig' builds,
> > which helps testers out.
> 
> At least for /dev/null, /dev/zero, and perhaps /dev/tty it would 
> definitely break things if the major+minor number is not static. I have 
> multiple chroot environments having only some minimal needed static 
> /dev subdir, with naturally no daemons or filesystem creating those 
> on-demand. For the main /dev I use whatever the system sets up, so 
> devtmpfs with udev.

No, it wouldn't be required, it would be an option for those people
using devtmpfs.

thanks,

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

Re: [Merge tag 'pci-v4.12-changes' of git] 857f864014: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8

[Greg Kroah-Hartman]

On Tue, Jun 13, 2017 at 10:25:40AM -0600, Logan Gunthorpe wrote:
> 
> 
> On 12/06/17 10:35 PM, Greg Kroah-Hartman wrote:
> > Or better yet, just turn all char major allocations into dynamic, which
> > would be really good for test systems.  I thought someone proposed
> > patches for that a long time ago, but I can't find them anymore.  That
> > would be the simplest solution here.
> 
> Would people not complain about that? I would not be surprised if some
> crazy application is using hard coded major numbers in userspace. So
> such a change could potentially break userspace...

For char devices, I doubt it, but we can't take the chance, which is why
you make it an option.  Then, it's enabled for 'allmodconfig' builds,
which helps testers out.

thanks,

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

Re: [Merge tag 'pci-v4.12-changes' of git] 857f864014: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8

[Greg Kroah-Hartman]

On Tue, Jun 13, 2017 at 06:34:16AM +0200, Greg Kroah-Hartman wrote:
> On Mon, Jun 12, 2017 at 10:29:20PM -0600, Logan Gunthorpe wrote:
> > 
> > 
> > On 12/06/17 10:18 PM, Greg Kroah-Hartman wrote:
> > > What test causes so many major numbers to be allocated?  Is this
> > > in-kernel test code?  Do you really have a system that requires so many
> > > different drivers that all want a dynamic char major?
> > 
> > This is a 0day kernel robot test. I'm not sure the motivations of its
> > design but it seems to be similar to an allyesconfig. So all/most
> > modules are compiled in and allocating their char device regions on boot
> > of a qemu instance.
> 
> Ah, that makes sense.  Well, someone can always work on expanding the
> range of dynamic char major numbers if they are running out of them on a
> real system, I'll gladly take patches for that :)

Or better yet, just turn all char major allocations into dynamic, which
would be really good for test systems.  I thought someone proposed
patches for that a long time ago, but I can't find them anymore.  That
would be the simplest solution here.

thnaks,

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

Re: [Merge tag 'pci-v4.12-changes' of git] 857f864014: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8

[Greg Kroah-Hartman]

On Mon, Jun 12, 2017 at 10:29:20PM -0600, Logan Gunthorpe wrote:
> 
> 
> On 12/06/17 10:18 PM, Greg Kroah-Hartman wrote:
> > What test causes so many major numbers to be allocated?  Is this
> > in-kernel test code?  Do you really have a system that requires so many
> > different drivers that all want a dynamic char major?
> 
> This is a 0day kernel robot test. I'm not sure the motivations of its
> design but it seems to be similar to an allyesconfig. So all/most
> modules are compiled in and allocating their char device regions on boot
> of a qemu instance.

Ah, that makes sense.  Well, someone can always work on expanding the
range of dynamic char major numbers if they are running out of them on a
real system, I'll gladly take patches for that :)

thanks,

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

Re: [Merge tag 'pci-v4.12-changes' of git] 857f864014: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8

[Greg Kroah-Hartman]

On Mon, Jun 12, 2017 at 05:34:59PM -0600, Logan Gunthorpe wrote:
> 1) The test we are looking at is overrunning the dynamic char dev major
> numbers by a lot. On a successful run, it gets down to 216 where the
> limit is 234. Thus, there are 18 too many major numbers assigned and the
> fact that this test used to work is really just luck. (I've cc'd
> developers from 49db08c3 for this issue.)

What test causes so many major numbers to be allocated?  Is this
in-kernel test code?  Do you really have a system that requires so many
different drivers that all want a dynamic char major?

thanks,

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

Re: [PATCH v15 00/13] mux controller abstraction and iio/i2c muxes

[Greg Kroah-Hartman]

On Sat, Jun 03, 2017 at 08:37:21PM +0200, Luc Van Oostenryck wrote:
> On Sat, Jun 3, 2017 at 12:26 PM, Greg Kroah-Hartman
> <gre...@linuxfoundation.org> wrote:
> > On Sun, May 14, 2017 at 09:51:03PM +0200, Peter Rosin wrote:
> >> From: Peter Rosin <p...@axentia.se>
> >>
> >> Hi Greg,
> >>
> >> Philipp found problems in v14 with using a mutex for locking that was
> >> the outcome of the review for v13, so I'm now using a semaphore instead
> >> of the rwsem that was in v13. That at least got rid of the scary call
> >> to downgrade_write. However, I'm still unsure about what you actually
> >> meant with your comment about lack of sparse markings [1]. I did add
> >> __must_check to the funcs that selects the mux, but I've got this
> >> feeling that this is not what you meant?
> >
> > I thought there was a way to mark a function as requiring a lock be held
> > when it is being called.  Does sparse not support that anymore?
> 
> sparse still support these annotations, of course.
> In this case, I suppose you're talking about '__must_hold()' which
> *must* be used instead of a pair of '__releases()' + '__acquires()'
> when the lock is help on function entry and exit.

Ah, yes, that's what I was thinking of.  I don't know if sparse can
track things like this across an exported symbol, so I doubt it really
will help here.  Sorry for the noise.

thanks,

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

Re: [PATCH v15 00/13] mux controller abstraction and iio/i2c muxes

[Greg Kroah-Hartman]

On Sat, Jun 03, 2017 at 07:26:27PM +0900, Greg Kroah-Hartman wrote:
> On Sun, May 14, 2017 at 09:51:03PM +0200, Peter Rosin wrote:
> > From: Peter Rosin <p...@axentia.se>
> > 
> > Hi Greg,
> > 
> > Philipp found problems in v14 with using a mutex for locking that was
> > the outcome of the review for v13, so I'm now using a semaphore instead
> > of the rwsem that was in v13. That at least got rid of the scary call
> > to downgrade_write. However, I'm still unsure about what you actually
> > meant with your comment about lack of sparse markings [1]. I did add
> > __must_check to the funcs that selects the mux, but I've got this
> > feeling that this is not what you meant?
> 
> I thought there was a way to mark a function as requiring a lock be held
> when it is being called.  Does sparse not support that anymore?

Anyway, not a big deal.  I still worry about the calls blocking when
people are not expecting them to, but it is just the nature of th api I
guess.

All now queued up, nice work, thanks for sticking with this.

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

Re: [PATCH v15 00/13] mux controller abstraction and iio/i2c muxes

[Greg Kroah-Hartman]

On Sun, May 14, 2017 at 09:51:03PM +0200, Peter Rosin wrote:
> From: Peter Rosin 
> 
> Hi Greg,
> 
> Philipp found problems in v14 with using a mutex for locking that was
> the outcome of the review for v13, so I'm now using a semaphore instead
> of the rwsem that was in v13. That at least got rid of the scary call
> to downgrade_write. However, I'm still unsure about what you actually
> meant with your comment about lack of sparse markings [1]. I did add
> __must_check to the funcs that selects the mux, but I've got this
> feeling that this is not what you meant?

I thought there was a way to mark a function as requiring a lock be held
when it is being called.  Does sparse not support that anymore?

thanks,

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

Re: [PATCH 10/30] kobject.txt: standardize document format

[Greg Kroah-Hartman]

On Thu, May 18, 2017 at 10:24:02PM -0300, Mauro Carvalho Chehab wrote:
> 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:
> 
> - Add markups for titles;
> - mark literal blocks as such;
> - add needed whitespace/blank lines;
> - use :Author: and :Last updated: for authorship.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>

Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] misc: Implement devm_misc_register

[Greg Kroah-Hartman]

On Tue, May 09, 2017 at 02:27:48AM +, Gregory Fong wrote:
> Add device managed devm_misc_register() to allow simplifying some
> miscdevice code.
> 
> Signed-off-by: Gregory Fong 
> ---
> This seemed like it would be handy for removing a large chunk of the cleanup
> code in various miscdevice users.  Let me know whether you think it'd be worth
> going ahead changing this throughout the codebase where appropriate.

I'd like to see how this is actually used before accepting it, as we
don't like adding apis that do not have any users.  So care to make this
a patch series, first one with this change, and the rest converting some
drivers to use it?

thanks,

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

Re: [PATCH v4 4/6] usb.rst: move documentation from proc_usb_info.txt to USB ReST book

[Greg Kroah-Hartman]

On Sun, Apr 16, 2017 at 09:51:09PM -0300, Mauro Carvalho Chehab wrote:
> The contents of proc_usb_info.txt complements what's there at
> driver-api usb book. Yet, it is outdated, as it still refers
> to the USB character devices as usbfs.
> 
> So, move the contents to usb.rst, adjusting it to point to
> the right places.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>

Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/6] usb: fix some references for /proc/bus/usb

[Greg Kroah-Hartman]

On Sun, Apr 16, 2017 at 09:51:07PM -0300, Mauro Carvalho Chehab wrote:
> Since when we got rid of usbfs, the /proc/bus/usb is now
> elsewhere. Fix references for it.
> 
> Signed-off-by: Mauro Carvalho Chehab 

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

Re: [PATCH v3 2/3] usb: fix some references for /proc/bus/usb

[Greg Kroah-Hartman]

On Sun, Apr 16, 2017 at 01:40:04PM -0300, Mauro Carvalho Chehab wrote:
> Since when we got rid of usbfs, the /proc/bus/usb is now
> elsewhere. Fix references for it.
> 
> Signed-off-by: Mauro Carvalho Chehab 

As this touches USB code, I'll take this in my tree.

thanks,

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

Re: [PATCH v13 03/10] mux: minimal mux subsystem and gpio-based mux controller

[Greg Kroah-Hartman]

On Thu, Apr 13, 2017 at 06:43:07PM +0200, Peter Rosin wrote:
> +config MUX_GPIO
> + tristate "GPIO-controlled Multiplexer"
> + depends on OF && GPIOLIB

Why have the gpio and mux core in the same patch?

And why does this depend on OF?


> + help
> +   GPIO-controlled Multiplexer controller.
> +
> +   The driver builds a single multiplexer controller using a number
> +   of gpio pins. For N pins, there will be 2^N possible multiplexer
> +   states. The GPIO pins can be connected (by the hardware) to several
> +   multiplexers, which in that case will be operated in parallel.
> +
> +   To compile the driver as a module, choose M here: the module will
> +   be called mux-gpio.
> +
> +endif
> diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
> new file mode 100644
> index ..bb16953f6290
> --- /dev/null
> +++ b/drivers/mux/Makefile
> @@ -0,0 +1,6 @@
> +#
> +# Makefile for multiplexer devices.
> +#
> +
> +obj-$(CONFIG_MULTIPLEXER)+= mux-core.o
> +obj-$(CONFIG_MUX_GPIO)   += mux-gpio.o
> diff --git a/drivers/mux/mux-core.c b/drivers/mux/mux-core.c
> new file mode 100644
> index ..66a8bccfc3d7
> --- /dev/null
> +++ b/drivers/mux/mux-core.c
> @@ -0,0 +1,422 @@
> +/*
> + * Multiplexer subsystem
> + *
> + * Copyright (C) 2017 Axentia Technologies AB
> + *
> + * Author: Peter Rosin 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#define pr_fmt(fmt) "mux-core: " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * The idle-as-is "state" is not an actual state that may be selected, it
> + * only implies that the state should not be changed. So, use that state
> + * as indication that the cached state of the multiplexer is unknown.
> + */
> +#define MUX_CACHE_UNKNOWN MUX_IDLE_AS_IS
> +
> +static struct class mux_class = {
> + .name = "mux",
> + .owner = THIS_MODULE,
> +};

No Documentation/ABI/ update for your sysfs files?  Please do so.

> +
> +static int __init mux_init(void)
> +{
> + return class_register(_class);
> +}
> +
> +static DEFINE_IDA(mux_ida);

When your module is unloaded, you forgot to clean this structure up with
what was done with it.

> +
> +static void mux_chip_release(struct device *dev)
> +{
> + struct mux_chip *mux_chip = to_mux_chip(dev);
> +
> + ida_simple_remove(_ida, mux_chip->id);
> + kfree(mux_chip);
> +}
> +
> +static struct device_type mux_type = {
> + .name = "mux-chip",
> + .release = mux_chip_release,
> +};
> +
> +struct mux_chip *mux_chip_alloc(struct device *dev,
> + unsigned int controllers, size_t sizeof_priv)
> +{
> + struct mux_chip *mux_chip;
> + int i;
> +
> + if (WARN_ON(!dev || !controllers))
> + return NULL;
> +
> + mux_chip = kzalloc(sizeof(*mux_chip) +
> +controllers * sizeof(*mux_chip->mux) +
> +sizeof_priv, GFP_KERNEL);
> + if (!mux_chip)
> + return NULL;

You don't return PTR_ERR(-ENOMEM)?  Ok, why not?  (I'm not arguing for
it, just curious...)

> +
> + mux_chip->mux = (struct mux_control *)(mux_chip + 1);
> + mux_chip->dev.class = _class;
> + mux_chip->dev.type = _type;
> + mux_chip->dev.parent = dev;
> + mux_chip->dev.of_node = dev->of_node;
> + dev_set_drvdata(_chip->dev, mux_chip);
> +
> + mux_chip->id = ida_simple_get(_ida, 0, 0, GFP_KERNEL);
> + if (mux_chip->id < 0) {
> + pr_err("muxchipX failed to get a device id\n");
> + kfree(mux_chip);
> + return NULL;
> + }
> + dev_set_name(_chip->dev, "muxchip%d", mux_chip->id);
> +
> + mux_chip->controllers = controllers;
> + for (i = 0; i < controllers; ++i) {
> + struct mux_control *mux = _chip->mux[i];
> +
> + mux->chip = mux_chip;
> + init_rwsem(>lock);
> + mux->cached_state = MUX_CACHE_UNKNOWN;
> + mux->idle_state = MUX_IDLE_AS_IS;
> + }
> +
> + device_initialize(_chip->dev);

Why are you not registering the device here as well?  Why have this be a
two step process?

> +
> + return mux_chip;
> +}
> +EXPORT_SYMBOL_GPL(mux_chip_alloc);
> +
> +static int mux_control_set(struct mux_control *mux, int state)
> +{
> + int ret = mux->chip->ops->set(mux, state);
> +
> + mux->cached_state = ret < 0 ? MUX_CACHE_UNKNOWN : state;
> +
> + return ret;
> +}
> +
> +int mux_chip_register(struct mux_chip *mux_chip)
> +{
> + int i;
> + int ret;
> +
> + for (i = 0; i < mux_chip->controllers; ++i) {
> + struct mux_control *mux = _chip->mux[i];
> +
> + if (mux->idle_state == mux->cached_state)
> + 

Re: [PATCH v2 00/21] Convert USB documentation to ReST format

[Greg Kroah-Hartman]

On Tue, Apr 11, 2017 at 03:36:39PM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 11 Apr 2017 16:58:40 +0200
> Greg Kroah-Hartman <gre...@linuxfoundation.org> escreveu:
> 
> > On Sat, Apr 08, 2017 at 10:04:33PM +0200, Greg Kroah-Hartman wrote:
> > > On Sat, Apr 08, 2017 at 11:23:28AM -0600, Jonathan Corbet wrote:  
> > > > On Wed,  5 Apr 2017 10:22:54 -0300
> > > > Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:
> > > >   
> > > > > Currently, there are several USB core documents that are at either
> > > > > written in plain text or in DocBook format. Convert them to ReST
> > > > > and add to the driver-api book.  
> > > > 
> > > > Greg, do you see any reason not to apply these for 4.12?  A few of them
> > > > touch comments outside of Documentation/; I'm happy to carry those or
> > > > leave them to you, as you prefer.  
> > > 
> > > I'll queue them up in the next few days, thanks!  
> > 
> > Nope, they don't apply to my tree, it was probably based on yours.  And
> > the first two are ones I shouldn't be taking.
> 
> Yeah, I based it at the docs-next tree. If you prefer, I can rebase
> on your tree, but I guess that the docbook conversion patches
> would likely conflict with some patches at docs-next, because of
> the Makefile changes.

Doesn't bother me, it can go through the Documentation tree as-is.

thanks,

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

Re: [PATCH v12 00/10] mux controller abstraction and iio/i2c muxes

[Greg Kroah-Hartman]

On Thu, Mar 30, 2017 at 09:34:52AM +0200, Peter Rosin wrote:
> On 2017-03-27 16:21, Peter Rosin wrote:
> > Hi Greg!
> > 
> > Please apply.
> >
> 
> *snip snip*
> 
> > v10 -> v11 changes
> > - added a new patch (12) with a fix for messed up error path reported
> >   by Paul Gortmaker.
> 
> Oops, should be Dan Carpenter. Sorry about that...
> 
> And, I forgot to high-light this:
> 
> > v4 -> v5 changes
> > - driver for Analog Devices ADG792A/G, literally the first mux chip
> >   I found on the Internet with an i2c interface (that was not a
> >   dedicated i2c multiplexer like PCA9547) which I used to verify
> >   that the abstractions in the mux core are up to the task. Untested,
> >   just proof of concept that at least looks pretty and compiles...
> 
> Maybe the patches related to adg792 (last two patches in v12) should
> not be applied? I don't care much either way, your call Greg...

Give me a chance to catch up on reviews, your patch series is behind
400+ other emails...

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

Re: [PATCH v11 11/12] iio: multiplexer: fix unsigned check with less than zero

[Greg Kroah-Hartman]

On Mon, Mar 27, 2017 at 03:46:47PM +0200, Peter Rosin wrote:
> On 2017-03-27 15:06, Johan Hovold wrote:
> > On Mon, Mar 27, 2017 at 02:17:48PM +0200, Peter Rosin wrote:
> >> Comparing a size_t with less than zero is always false as size_t
> >> is unsigned. So, change the type of the variable to ssize_t and
> >> replicate the size check from mux_configure_channel() into
> >> mux_write_ext_info() thus ensuring that the size will fit in the
> >> ssize_t variable.
> >>
> >> Detected by CoverityScan, CID#1415278 ("Unsigned compared against 0")
> >>
> >> Fixes: 1da8e16d2812 ("iio: multiplexer: new iio category and iio-mux 
> >> driver")
> > 
> > You should fold this one and the next patch into the patches that they
> > fix up instead fixing stuff that's not yet merged incrementally like you
> > do here (specifically, the SHA id above will have no matching commit).
> > 
> > Johan
> 
> I forgot about that. And similar for the next patch. But how do you
> propose that I attribute the reporters and CoverityScan? Crap, it
> would have been so much easier if the series was just pulled they
> way I expected it...
> 
> Greg, how do you want to play this? Can you perhaps update the fixes
> tag here and in 12/12 if/when you apply the series?

Please fix this up and resend the patches properly.

thanks,

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

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

[Greg Kroah-Hartman]

On Tue, Feb 28, 2017 at 10:11:56AM -0700, Logan Gunthorpe wrote:
> In any case, I also wish we could have had this discussion 3 months ago
> when we posted the RFC and not when I have people pushing to get this
> merged.

Relax, there is no rush here, no deadlines, etc.  Moving the files to a
different directly takes all of 5 minutes, max.

mellow out dude,

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

Re: [PATCH v9 00/10] mux controller abstraction and iio/i2c muxes

[Greg Kroah-Hartman]

On Tue, Feb 28, 2017 at 04:17:52PM +0100, Peter Rosin wrote:
> Hi!
> 
> The status of this series [1] is that Rob Herring has acked/reviewed all
> devicetree changes, so I suppose that's ok. Jonathan Cameron has acked
> the additions to the iio subsystem and reviewed the new iio driver.
> Wolfram Sang has acked the i2c-mux driver. That's acks or reviews from
> the maintainers for all changes to the maintained areas.
> 
> What's not covered by the above is the mux subsystem itself. Jonathan
> has also acked or reviewed those changes, but I get the feeling that
> more tags are desired? So, please review the core of the mux subsystem
> and the two drivers! It's small. Really. And much of it is boilerplate
> devm functions. The relevant patches are:
> 
>  3/10 "mux: minimal mux subsystem and gpio-based mux controller"
> 10/10 "mux: adg792a: add mux controller driver for ADG792A/G"
> 
> I also wonder how I should proceed next. Jonathan kindly provided some
> hints. I have created a project on gitlab [2] to track future mux
> changes and where this series is also available (in the "mux" branch,
> of course subject to rebases, at least for now). I intend to create a
> for-next branch that I hope Stephen Rothwell will be happy to add to
> linux-next at some point after v4.11-rc1. Whomever I will feed future
> changes to will also pull from that tree. Etc. At least that's my
> picture of how this is going to work.
> 
> The question then becomes to whom I will send pull requests? My guess is
> that the plausible candidates are Greg K-H, Linus Torvalds and Andrew
> Morton. Any taker? Are there other candidates? I don't have any particular
> preference. If I don't hear anything I'll probably just send a pull
> request to Linus for the next merge window (i.e. targeting 4.12-rc1).
> 
> Or am I perhaps getting ahead of myself? Is a new tree overkill? I
> don't expect it to be exactly busy...

I pull in lots of semi-random driver subsystems into my char-misc driver
tree, and I can do that here for you as well if you want me to, to
forward things on to Linus at the proper times.

Just let me know.

thanks,

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

Re: [PATCH v2 0/4] New Microsemi PCI Switch Management Driver

[Greg Kroah-Hartman]

On Thu, Feb 23, 2017 at 01:36:51PM -0700, Logan Gunthorpe wrote:
> Hello,
> 
> We're still waiting on any kind of response from Bjorn. (If you're
> listening please say something!)
> 
> Does anyone have any suggestions for dealing with an unresponsive
> maintainer? Or a way for us to move forward with this quickly and get it
> merged?

It's the middle of the merge window, nothing new can go in right now.
Wait until after 4.11-rc1 comes out before expecting for maintainers to
be able to start reviewing and discussing new things like this.

patience please,

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

Re: [PATCH v3] tty: pl011: Work around QDF2400 E44 stuck BUSY bit

[Greg Kroah-Hartman]

On Wed, Feb 15, 2017 at 07:50:27PM +, Mark Rutland wrote:
> On Wed, Feb 15, 2017 at 01:01:59PM -0500, Christopher Covington wrote:
> > The Qualcomm Datacenter Technologies QDF2400 family of SoCs contains a
> > custom (non-PrimeCell) implementation of the SBSA UART. Occasionally the
> > BUSY bit in the Flag Register gets stuck as 1, erratum 44 for both 2432v1
> > and 2400v1 SoCs.Checking that the Transmit FIFO Empty (TXFE) bit is 0,
> > instead of checking that the BUSY bit is 1, works around the issue.
> > 
> > To facilitate this substitution of flags and values, introduce
> > vendor-specific inversion of Feature Register bits when UART AMBA Port
> > (UAP) data is available. For the earlycon case, prior to UAP availability,
> > implement alternative putc and early_write functions.
> > 
> > Similar to what how ARMv8 ACPI PCI quirks are detected during MCFG parsing,
> > check the OEM fields of the Serial Port Console Redirection (SPCR) ACPI
> > table to determine if the current platform is known to be affected by the
> > erratum.
> > 
> > Signed-off-by: Christopher Covington 
> > Acked-by: Russell King 
> > ---
> > Since v2: Formatting and other improvements per Timur's suggestions
> > Due to known (although trivial) conflicts in silicon-errata.txt, based on
> > http://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/log/?h=for-next/core
> > ---
> >  Documentation/arm64/silicon-errata.txt |  2 ++
> >  drivers/acpi/spcr.c| 23 
> >  drivers/tty/serial/amba-pl011.c| 66 
> > ++
> >  3 files changed, 84 insertions(+), 7 deletions(-)
> > 
> > diff --git a/Documentation/arm64/silicon-errata.txt 
> > b/Documentation/arm64/silicon-errata.txt
> > index a71b8095dbd8..bc3d086bc624 100644
> > --- a/Documentation/arm64/silicon-errata.txt
> > +++ b/Documentation/arm64/silicon-errata.txt
> > @@ -68,3 +68,5 @@ stable kernels.
> >  || | | 
> > |
> >  | Qualcomm Tech. | Falkor v1   | E1003   | 
> > QCOM_FALKOR_ERRATUM_1003|
> >  | Qualcomm Tech. | Falkor v1   | E1009   | 
> > QCOM_FALKOR_ERRATUM_1009|
> > +| Qualcomm Tech. | QDF2432v1 UART  | SoC E44 | N/A 
> > |
> > +| Qualcomm Tech. | QDF2400v1 UART  | SoC E44 | N/A 
> > |
> > diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
> > index b8019c4c1d38..2b5d0fac81f0 100644
> > --- a/drivers/acpi/spcr.c
> > +++ b/drivers/acpi/spcr.c
> > @@ -16,6 +16,26 @@
> >  #include 
> >  #include 
> >  
> > +/*
> > + * Some Qualcomm Datacenter Technologies SoCs have a defective UART BUSY 
> > bit.
> > + * Detect them by examining the OEM fields in the SPCR header, similiar to 
> > PCI
> > + * quirk detection in pci_mcfg.c.
> > + */
> > +static bool qdf2400_erratum_44_present(struct acpi_table_header *h)
> > +{
> > +   if (memcmp(h->oem_id, "QCOM  ", ACPI_OEM_ID_SIZE))
> > +   return false;
> > +
> > +   if (!memcmp(h->oem_table_id, "QDF2432 ", ACPI_OEM_TABLE_ID_SIZE))
> > +   return true;
> > +
> > +   if (!memcmp(h->oem_table_id, "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) &&
> > +   h->oem_revision == 0)
> > +   return true;
> > +
> > +   return false;
> > +}
> > +
> >  /**
> >   * parse_spcr() - parse ACPI SPCR table and add preferred console
> >   *
> > @@ -93,6 +113,9 @@ int __init parse_spcr(bool earlycon)
> > goto done;
> > }
> >  
> > +   if (qdf2400_erratum_44_present(>header))
> > +   uart = "qdf2400_e44";
> > +
> 
> This addresses my concern with using the MIDR; thanks for respinning
> this. FWIW:
> 
> Acked-by: Mark Rutland 
> 
> It might be best to split the silicon-errata doc into a separate patch.
> That can go via the arm64 tree without conflict whiel the driver patch
> can go via the tty tree.

Well, I can't take this as-is because I get conflicts in my tty tree
with the doc, and with the driver itself:

checking file Documentation/arm64/silicon-errata.txt
Hunk #1 FAILED at 68.
1 out of 1 hunk FAILED
checking file drivers/acpi/spcr.c
checking file drivers/tty/serial/amba-pl011.c
Hunk #5 FAILED at 2370.
1 out of 8 hunks FAILED

I have no idea what the driver conflict is, what branch was this made
against?

thanks,

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

Re: [PATCH v2 1/4] MicroSemi Switchtec management interface driver

[Greg Kroah-Hartman]

On Fri, Feb 10, 2017 at 10:03:10AM -0700, Logan Gunthorpe wrote:
> 
> 
> On 10/02/17 09:55 AM, Greg Kroah-Hartman wrote:
> > Yes, but try it yourself to verify it really is correct :)
> 
> Yes, of course... turns out it wasn't. I accidentally refereed to dev
> before I assigned it. I had mainly just wanted your feedback to ensure
> that switching to device_register made sense.
> 
> > And it can just be an add-on patch, no need to respin a whole new
> > version for just that simple change, it doesn't hurt anything as-is,
> > it's just "not needed".
> 
> Ok... How should I do that exactly? Attempt to reply to the thread with
> another patch?

Sure, or just wait for these to be applied to the PCI tree and then send
a follow-on patch.  It's up to Bjorn really, as to what he wants.

thanks,

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

Re: [PATCH v2 1/4] MicroSemi Switchtec management interface driver

[Greg Kroah-Hartman]

On Fri, Feb 10, 2017 at 09:48:37AM -0700, Logan Gunthorpe wrote:
> Hey Greg,
> 
> Thanks so much for the review.
> 
> On 10/02/17 07:51 AM, Greg Kroah-Hartman wrote:
> > On Thu, Feb 02, 2017 at 11:06:00AM -0700, Logan Gunthorpe wrote:
> >> +  cdev = >cdev;
> >> +  cdev_init(cdev, _fops);
> >> +  cdev->owner = THIS_MODULE;
> >> +  cdev->kobj.parent = >kobj;
> > 
> > Minor nit, the kobject in a cdev is unlike any other kobject you have
> > ever seen, don't mess with it, it's not doing anything like you think it
> > is doing.  So no need to set the parent field.
> 
> Ok, that makes sense. I'll do a v3 shortly.
> 
> I copied this from drivers/dax/dax.c so when I have a spare moment I'll
> submit a patch to remove it from there as well.
> 
> Just to make sure I get this right without extra churn: does this look
> correct?
> 
> 
> cdev = >cdev;
> cdev_init(cdev, _fops);
> cdev->owner = THIS_MODULE;
> 
> rc = cdev_add(>cdev, dev->devt, 1);
> if (rc)
> goto err_cdev;
> 
> dev = >dev;
> dev->devt = MKDEV(MAJOR(switchtec_devt), minor);
> dev->class = switchtec_class;
> dev->parent = >dev;
> dev->groups = switchtec_device_groups;
> dev->release = stdev_release;
> dev_set_name(dev, "switchtec%d", minor);
> 
> rc = device_register(dev);
> if (rc) {
> cdev_del(>cdev);
> put_device(dev);
> return ERR_PTR(rc);
> }
> 

Yes, but try it yourself to verify it really is correct :)

And it can just be an add-on patch, no need to respin a whole new
version for just that simple change, it doesn't hurt anything as-is,
it's just "not needed".

thanks,

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

Re: [PATCH v2 1/4] MicroSemi Switchtec management interface driver

[Greg Kroah-Hartman]

On Thu, Feb 02, 2017 at 11:06:00AM -0700, Logan Gunthorpe wrote:
> Microsemi's "Switchtec" line of PCI switch devices is already well
> supported by the kernel with standard PCI switch drivers. However, the
> Switchtec device advertises a special management endpoint with a separate
> PCI function address and class code. This endpoint enables some additional
> functionality which includes:
> 
>  * Packet and Byte Counters
>  * Switch Firmware Upgrades
>  * Event and Error logs
>  * Querying port link status
>  * Custom user firmware commands
> 
> This patch introduces the switchtec kernel module which provides
> PCI driver that exposes a char device. The char device provides
> userspace access to this interface through read, write and (optionally)
> poll calls.
> 
> A userspace tool and library which utilizes this interface is available
> at [1]. This tool takes inspiration (and borrows some code) from
> nvme-cli [2]. The tool is largely complete at this time but additional
> features may be added in the future.
> 
> [1] https://github.com/sbates130272/switchtec-user
> [2] https://github.com/linux-nvme/nvme-cli
> 
> Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
> Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com>

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/4] MicroSemi Switchtec management interface driver

[Greg Kroah-Hartman]

On Thu, Feb 02, 2017 at 11:06:00AM -0700, Logan Gunthorpe wrote:
> + cdev = >cdev;
> + cdev_init(cdev, _fops);
> + cdev->owner = THIS_MODULE;
> + cdev->kobj.parent = >kobj;

Minor nit, the kobject in a cdev is unlike any other kobject you have
ever seen, don't mess with it, it's not doing anything like you think it
is doing.  So no need to set the parent field.

thanks,

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

Re: [PATCH 1/1] MicroSemi Switchtec management interface driver

[Greg Kroah-Hartman]

On Tue, Jan 31, 2017 at 10:35:44AM -0700, Logan Gunthorpe wrote:
> 
> 
> On 31/01/17 10:26 AM, Greg Kroah-Hartman wrote:
> > That's one big patch to review, would you want to do that?
> 
> Sorry, will do.
> 
> > Can you break it up into smaller parts?  At least put the documentation
> > separately, right?
> 
> Ha, funny. Last time I sent a patch someone asked for the documentation
> to be in the same patch. But I can easily split this up.

Sorry, it was probably me :)

> > And don't dump a .txt file into Documentation/ anymore, people are
> > working to move to the newer format.
> 
> Fair. I wasn't sure where a good place to put it was. Any suggestions?

Why do you need this?  Wherever you put it, it should be built as part
of the online kernel documentation.  Who is the audience for this
documentation?

> > Also, please rebase against Linus's tree at the least, we can't go back
> > in time and apply this to the 4.9 kernel tree.
> 
> Will do.
> 
> > Why a .h file for a single .c file?
> 
> I wanted to keep the hardware defining structs and macros in a separate
> file for future expansion. This hardware is also capable of some NTB
> functions which may find it's way into the kernel in the future.

Do future stuff in the future, no need for that now, right?

Simple is best.

> > Also, why a whole new directory?
> 
> We didn't feel it fit in the pci director which was for standard pci
> stuff. We're more than open to other suggestions as to where this code
> belongs.

I'll leave that up to the PCI maintainer, but just a single .c file in a
subdir seems odd to me.

thanks,

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

Re: [PATCH 1/1] MicroSemi Switchtec management interface driver

[Greg Kroah-Hartman]

On Tue, Jan 31, 2017 at 10:03:24AM -0700, Logan Gunthorpe wrote:
> Microsemi's "Switchtec" line of PCI switch devices is already well
> supported by the kernel with standard PCI switch drivers. However, the
> Switchtec device advertises a special management endpoint with a separate
> PCI function address and class code. This endpoint enables some additional
> functionality which includes:
> 
>  * Packet and Byte Counters
>  * Switch Firmware Upgrades
>  * Event and Error logs
>  * Querying port link status
>  * Custom user firmware commands
> 
> This patch introduces the switchtec kernel module which provides
> PCI driver that exposes a char device. The char device provides
> userspace access to this interface through read, write and (optionally)
> poll calls. A couple of special IOCTLs are provided to:
> 
> * Inform userspace of firmware partition locations
> * Pass event counts and allow userspace to wait on events
> 
> A short text file is provided which documents the switchtec driver,
> outlines the semantics of using the char device and describes the
> IOCTLs.
> 
> The device also exposes a few read-only sysfs attributes which provide
> some device information component names and versions which is provided
> by the hardware. These are documented in
> Documentation/ABI/testing/sysfs-class-switchtec
> 
> A userspace tool and library which utilizes this interface is available
> at [1]. This tool takes inspiration (and borrows some code) from
> nvme-cli [2]. The tool is largely complete at this time but additional
> features may be added in the future.
> 
> [1] https://github.com/sbates130272/switchtec-user
> [2] https://github.com/linux-nvme/nvme-cli
> 
> Signed-off-by: Logan Gunthorpe 
> Signed-off-by: Stephen Bates 
> ---
>  Documentation/ABI/testing/sysfs-class-switchtec |   96 ++
>  Documentation/ioctl/ioctl-number.txt|1 +
>  Documentation/switchtec.txt |   80 ++
>  MAINTAINERS |   11 +
>  drivers/pci/Kconfig |1 +
>  drivers/pci/Makefile|1 +
>  drivers/pci/switch/Kconfig  |   13 +
>  drivers/pci/switch/Makefile |1 +
>  drivers/pci/switch/switchtec.c  | 1320 
> +++
>  drivers/pci/switch/switchtec.h  |  266 +

Why a .h file for a single .c file?

Also, why a whole new directory?

thanks,

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

Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging

[Greg Kroah-Hartman]

On Tue, Jan 03, 2017 at 10:19:29PM +0100, Arnd Bergmann wrote:
> On Tuesday, January 3, 2017 4:24:36 PM CET Greg Kroah-Hartman wrote:
> > On Wed, Mar 02, 2016 at 08:06:46PM +0100, Arnd Bergmann wrote:
> > > The icn, act2000 and pcbit drivers are all for very old hardware,
> > > and it is highly unlikely that anyone is actually still using them
> > > on modern kernels, if at all.
> > > 
> > > All three drivers apparently are for hardware that predates PCI
> > > being the common connector, as they are ISA-only and active
> > > PCI ISDN cards were widely available in the 1990s.
> > > 
> > > Looking through the git logs, it I cannot find any indication of a
> > > patch to any of these drivers that has been tested on real hardware,
> > > only cleanups or global API changes.
> > > 
> > > Signed-off-by: Arnd Bergmann <a...@arndb.de>
> > > Acked-by: Karsten Keil <i...@linux-pingi.de>
> > 
> > This patch got added in the 4.6 kernel release.  As I am now taking
> > patches for 4.11-rc1, I figure it is time to just delete the
> > drivers/staging/i4l/ directory now, given that no one has really done
> > anything with it.  If people show up that wish to maintain it, I'll be
> > glad to revert it, or if someone really screams in the next week.
> > Otherwise it's time to just move on 
> 
> Sounds good to me.

Ok, now deleted!

thanks,

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

Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging

[Greg Kroah-Hartman]

On Wed, Mar 02, 2016 at 08:06:46PM +0100, Arnd Bergmann wrote:
> The icn, act2000 and pcbit drivers are all for very old hardware,
> and it is highly unlikely that anyone is actually still using them
> on modern kernels, if at all.
> 
> All three drivers apparently are for hardware that predates PCI
> being the common connector, as they are ISA-only and active
> PCI ISDN cards were widely available in the 1990s.
> 
> Looking through the git logs, it I cannot find any indication of a
> patch to any of these drivers that has been tested on real hardware,
> only cleanups or global API changes.
> 
> Signed-off-by: Arnd Bergmann 
> Acked-by: Karsten Keil 

This patch got added in the 4.6 kernel release.  As I am now taking
patches for 4.11-rc1, I figure it is time to just delete the
drivers/staging/i4l/ directory now, given that no one has really done
anything with it.  If people show up that wish to maintain it, I'll be
glad to revert it, or if someone really screams in the next week.
Otherwise it's time to just move on :)

thanks,

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

Re: [PATCH v3 4/4] firmware: remove warning at documentation generation time

[Greg Kroah-Hartman]

On Thu, Dec 01, 2016 at 05:11:54PM +0100, Luis R. Rodriguez wrote:
> On Fri, Nov 25, 2016 at 06:50:32PM -0200, Mauro Carvalho Chehab wrote:
> > Em Fri, 25 Nov 2016 15:59:47 +0100
> > Silvio Fricke  escreveu:
> > 
> > > This patch removes following error at for `make htmldocs`. No functional
> > > change.
> > > 
> > >   ./drivers/base/firmware_class.c:1348: WARNING: Bullet list ends without 
> > > a blank line; unexpected unindent.
> > > 
> > > Signed-off-by: Silvio Fricke 
> > 
> > Reviewed-by: Mauro Carvalho Chehab 
> 
> Acked-by: Luis R. Rodriguez 
> 
> Jonathan,
> 
> firmware_class changes have been lately going through Greg's tree, he has a 
> few
> more pending changes on his driver-core-next branch for firmware_class but 
> this
> patch not create a conflict. It can go in first or later as such its
> technically fine for it to go either through your tree or Greg's tree.
> 
> I'll let Greg decide. I've bounced him a copy of the patch.

I can just take this one in my tree as it's easy to merge as-is.

thanks,

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

Re: [PATCH 3/3] doc-rst: add an ABI book

[Greg Kroah-Hartman]

On Fri, Oct 28, 2016 at 11:33:51AM -0200, Mauro Carvalho Chehab wrote:
> Em Fri, 28 Oct 2016 08:49:12 -0400
> Greg Kroah-Hartman <gre...@linuxfoundation.org> escreveu:
> 
> > On Fri, Oct 28, 2016 at 08:31:57AM -0400, Greg Kroah-Hartman wrote:
> > > On Fri, Oct 28, 2016 at 10:19:47AM -0200, Mauro Carvalho Chehab wrote:  
> > > > Use a script to parse the Documenation/ABI directory and output
> > > > it at the admin-guide.
> > > > 
> > > > Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> > > > ---
> > > >  Documentation/admin-guide/abi.rst   |   5 +
> > > >  Documentation/admin-guide/index.rst |   1 +
> > > >  Documentation/sphinx/abi_book.pl| 208 
> > > > 
> > > >  3 files changed, 214 insertions(+)
> > > >  create mode 100644 Documentation/admin-guide/abi.rst
> > > >  create mode 100755 Documentation/sphinx/abi_book.pl  
> > > 
> > > Any hint as to what the output of this actually looks like?  
> > 
> > Doh, you already showed it in patch 0/3, that's what I get for never
> > reading cover letters...
> 
> :-)
> 
> > sorry for the noise,
> 
> No problem. 
> 
> Btw, looking at the output of the script, I noticed a
> few files where "What" doesn't point to configfs/sysfs/procfs:
> 
> - Documentation/ABI/testing/sysfs-class-rtc-rtc0-device-rtc_calibration
>   What:   Attribute for calibrating ST-Ericsson AB8500 Real Time 
> Clock
> 
> This is probably a sysfs interface, so, IMHO, "What" here is wrong.
> 
> From the name of the file, I suspect that it should be, instead:
>   What:   /sysfs/class/rtc/rtc0/device/rtc_calibration
>   

Looks right, but the original authors would know more.

> - Documentation/ABI/stable/thermal-notification
>   What:   A notification mechanism for thermal related events
> 
> Not sure what kind of interface this is referring to. Perhaps a
> sysctl interface?

It's a netlink api, odd, haven't seen that before.

> - Documentation/ABI/stable/syscalls
>   What:   The kernel syscall interface
> 
> This sounds OK, although it probably makes sense to document
> each system call.

Heh, that's the whole man page project, I don't think we want to suck
that into the kernel just yet :)

> - Documentation/ABI/testing/sysfs-devices-system-ibm-rtl
>   What:   state
>   What:   version
> 
> According with their descriptions, both are needed for the
> "ibm-prtm" userspace daemon, but it provides no glue where
> this should be located. Looking at its source file, it seems
> that they should be located at [1]:
> 
>   /sys/devices/system/ibm_rtl/state
>   and
>   /proc/version
> 
> Btw, IMHO, it doesn't make much sense to document /proc/version
> inside sysfs-devices-system-ibm-rtl.

That might be a sysfs version file, not /proc/version, as it doesn't
look like /proc/version is described that way.

thanks,

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

Re: [PATCH 3/3] doc-rst: add an ABI book

[Greg Kroah-Hartman]

On Fri, Oct 28, 2016 at 08:31:57AM -0400, Greg Kroah-Hartman wrote:
> On Fri, Oct 28, 2016 at 10:19:47AM -0200, Mauro Carvalho Chehab wrote:
> > Use a script to parse the Documenation/ABI directory and output
> > it at the admin-guide.
> > 
> > Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> > ---
> >  Documentation/admin-guide/abi.rst   |   5 +
> >  Documentation/admin-guide/index.rst |   1 +
> >  Documentation/sphinx/abi_book.pl| 208 
> > 
> >  3 files changed, 214 insertions(+)
> >  create mode 100644 Documentation/admin-guide/abi.rst
> >  create mode 100755 Documentation/sphinx/abi_book.pl
> 
> Any hint as to what the output of this actually looks like?

Doh, you already showed it in patch 0/3, that's what I get for never
reading cover letters...

sorry for the noise,

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

Re: ABI conversion to ReST - Was: Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

[Greg Kroah-Hartman]

On Fri, Oct 28, 2016 at 10:20:57AM -0200, Mauro Carvalho Chehab wrote:
> Em Fri, 28 Oct 2016 06:28:23 -0400
> Greg Kroah-Hartman <gre...@linuxfoundation.org> escreveu:
> 
> > On Fri, Oct 28, 2016 at 08:14:21AM -0200, Mauro Carvalho Chehab wrote:
> > > Em Fri, 28 Oct 2016 02:54:33 -0400
> > > Greg Kroah-Hartman <gre...@linuxfoundation.org> escreveu:
> > >   
> > > > On Thu, Oct 27, 2016 at 10:34:05PM -0200, Mauro Carvalho Chehab wrote:  
> > > > > As defined at Documentation/ABI/README, this is actually a database
> > > > > with those fields:
> > > > > 
> > > > > What, Date, KernelVersion, Contact, Description and Users.
> > > > > 
> > > > > An user-face documentation would probably require only a few of those
> > > > > fields (like What and Description), but the entries should be
> > > > > probably sorted by the What field.
> > > > > 
> > > > > So, I suspect it wouldn't be hard to write a perl script to parse it
> > > > > and generate an ABI guide. On the other hand, we might need to fix
> > > > > some documents, if the parser fails due to some typo.
> > > > 
> > > > That sounds like a good plan to me, and patches to fix up typos to keep
> > > > things being able to be parsed properly should be fine.  
> > > 
> > > I started coding a parse script and already got some syntax issues ;)
> > > 
> > > See enclosed. Do you want me to break it per file?  
> > 
> > Nothing was attached :(
> 
> Sorry. Just sent it, together with another fixup patch, and the parser
> utility. Please let me know if you prefer if I break the first patch
> on per file (or per subsystem) ones.

Nope, it's good as-is.

Thanks for doing this, it's great to see this type of thing possible
with these documentation tool changes.

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

Re: [PATCH 3/3] doc-rst: add an ABI book

[Greg Kroah-Hartman]

On Fri, Oct 28, 2016 at 10:19:47AM -0200, Mauro Carvalho Chehab wrote:
> Use a script to parse the Documenation/ABI directory and output
> it at the admin-guide.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  Documentation/admin-guide/abi.rst   |   5 +
>  Documentation/admin-guide/index.rst |   1 +
>  Documentation/sphinx/abi_book.pl| 208 
> 
>  3 files changed, 214 insertions(+)
>  create mode 100644 Documentation/admin-guide/abi.rst
>  create mode 100755 Documentation/sphinx/abi_book.pl

Any hint as to what the output of this actually looks like?

No matter, I like this, thanks for doing this, it should be really
helpful.

Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] ABI: sysfs-driver-hid: the "What" field doesn't parse fine

[Greg Kroah-Hartman]

On Fri, Oct 28, 2016 at 10:19:46AM -0200, Mauro Carvalho Chehab wrote:
> The What: field on this ABI description use a different
> syntax than expected, causing it to not be properly parsed
> by script.
> 
> Fix it.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>

Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ABI: fix some syntax issues at the ABI database

[Greg Kroah-Hartman]

On Fri, Oct 28, 2016 at 10:19:45AM -0200, Mauro Carvalho Chehab wrote:
> On those three files, the ABI representation described at
> README are violated.
> 
> - at sysfs-bus-iio-proximity-as3935:
>   a ':' character is missing after "What"
> 
> - at sysfs-class-devfreq:
>   there's a typo at Description
> 
> - at sysfs-class-cxl, it is using the ":" character at a
>   file preamble, causing it to be misinterpreted as a
>   tag.
> 
> - On the other files, instead of "What", they use "Where".
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>

Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ABI conversion to ReST - Was: Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

[Greg Kroah-Hartman]

On Fri, Oct 28, 2016 at 08:14:21AM -0200, Mauro Carvalho Chehab wrote:
> Em Fri, 28 Oct 2016 02:54:33 -0400
> Greg Kroah-Hartman <gre...@linuxfoundation.org> escreveu:
> 
> > On Thu, Oct 27, 2016 at 10:34:05PM -0200, Mauro Carvalho Chehab wrote:
> > > As defined at Documentation/ABI/README, this is actually a database
> > > with those fields:
> > > 
> > > What, Date, KernelVersion, Contact, Description and Users.
> > > 
> > > An user-face documentation would probably require only a few of those
> > > fields (like What and Description), but the entries should be
> > > probably sorted by the What field.
> > > 
> > > So, I suspect it wouldn't be hard to write a perl script to parse it
> > > and generate an ABI guide. On the other hand, we might need to fix
> > > some documents, if the parser fails due to some typo.  
> > 
> > That sounds like a good plan to me, and patches to fix up typos to keep
> > things being able to be parsed properly should be fine.
> 
> I started coding a parse script and already got some syntax issues ;)
> 
> See enclosed. Do you want me to break it per file?

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

Re: ABI conversion to ReST - Was: Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

[Greg Kroah-Hartman]

On Thu, Oct 27, 2016 at 10:34:05PM -0200, Mauro Carvalho Chehab wrote:
> As defined at Documentation/ABI/README, this is actually a database
> with those fields:
> 
> What, Date, KernelVersion, Contact, Description and Users.
> 
> An user-face documentation would probably require only a few of those
> fields (like What and Description), but the entries should be
> probably sorted by the What field.
> 
> So, I suspect it wouldn't be hard to write a perl script to parse it
> and generate an ABI guide. On the other hand, we might need to fix
> some documents, if the parser fails due to some typo.

That sounds like a good plan to me, and patches to fix up typos to keep
things being able to be parsed properly should be fine.

thanks,

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

Re: [PATCH] docs-rst: add inter-document cross references

[Greg Kroah-Hartman]

On Wed, Sep 21, 2016 at 08:51:05AM -0300, Mauro Carvalho Chehab wrote:
> Add cross references for the development process documents
> that were converted to ReST:
>   Documentation/SubmitChecklist
>   Documentation/SubmittingDrivers
>   Documentation/SubmittingPatches
>   Documentation/development-process/development-process.rst
>   Documentation/stable_kernel_rules.txt
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
> 
> The changes here were at patch 29/29, that did the rename. I opted to
> split this change to just add the cross-references without the rename, as
> it makes easier if we decide to use symlinks instead of renames.
> 
> As I rebased the rename patch as well, on the top of this one, we can
> also use the rename, if people find it better.

For the stable_kernel_rules.txt portion:

Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/8] uio: fix dmem_region_start computation

[Greg Kroah-Hartman]

On Fri, Jul 15, 2016 at 02:34:00PM +0530, Anup Patel wrote:
> From: Jan Viktorin 
> 
> The variable i contains a total number of resources (including
> IORESOURCE_IRQ). However, we want the dmem_region_start to point
> after the last resource of type IORESOURCE_MEM. The original behaviour
> leads (very likely) to skipping several UIO mapping regions and makes
> them useless. Fix this by computing dmem_region_start from the uiomem
> which points to the last used UIO mapping.
> 
> Fixes: 0a0c3b5a24bd ("Add new uio device for dynamic memory allocation")
> 
> Signed-off-by: Jan Viktorin 
> ---
>  drivers/uio/uio_dmem_genirq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Why isn't this patch first in the series, with a stable marking, and
your signed off on it (you are forwarding it on to me, so you need to
add your mark to it as well, I can't take it otherwise.)

> diff --git a/drivers/uio/uio_dmem_genirq.c b/drivers/uio/uio_dmem_genirq.c
> index 915facb..e1134a4 100644
> --- a/drivers/uio/uio_dmem_genirq.c
> +++ b/drivers/uio/uio_dmem_genirq.c
> @@ -229,7 +229,7 @@ static int uio_dmem_genirq_probe(struct platform_device 
> *pdev)
>   ++uiomem;
>   }
>  
> - priv->dmem_region_start = i;
> + priv->dmem_region_start = uiomem - >mem[0];

Are you sure about this?  It doesn't look correct at first glance, I'm
loath to take this without a bunch of testing.  Were you able to test
this out to verify it doesn't break working hardware?

thanks,

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

Re: [PATCH v4] tty: serial: meson: Implement earlycon support

[Greg Kroah-Hartman]

On Wed, Mar 23, 2016 at 11:39:36AM +0100, Andreas Färber wrote:
> Am 06.03.2016 um 12:21 schrieb Andreas Färber:
> > Split off the bulk of the existing meson_serial_console_write()
> > implementation into meson_serial_port_write() for implementing
> > meson_serial_early_console_write().
> > 
> > Use "meson" as the earlycon driver name, courtesy of Nicolas.
> > 
> > Signed-off-by: Nicolas Saenz Julienne 
> > Acked-by: Carlo Caione 
> > Signed-off-by: Andreas Färber 
> > ---
> >  v3 -> v4:
> >  * Select SERIAL_EARLYCON (Arnd)
> 
> Ping?

It's the middle of the merge window, there's nothing I can do at the
moment, please wait for after 4.6-rc1 is out before I can start catching
up...

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

Re: [PATCH] Documentation: update the devices.txt documentation

[Greg Kroah-Hartman]

On Fri, Feb 19, 2016 at 09:17:36PM +0100, Linus Walleij wrote:
> Alan is no longer maintaining this list through the Linux assigned
> numbers authority. Make it a collective document by referring to
> "the maintainers" in plural throughout, and naming the chardev and
> block layer maintainers in particular as parties of involvement.
> Cut down and remove some sections that pertained to the process of
> maintaining the list at lanana.org and contacting Alan directly.
> 
> Make it clear that this document, in the kernel, is the master
> document.
> 
> Also move paragraphs around so as to emphasize dynamic major number
> allocation.
> 
> Remove paragraph on 2.6 deprecation, that tag no longer appears
> anywhere in the file.
> 
> Cc: Jonathan Corbet <cor...@lwn.net>
> Cc: Linus Torvalds <torva...@linux-foundation.org>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Cc: Alan Cox <a...@linux.intel.com>
> Cc: Arnd Bergmann <a...@arndb.de>
> Cc: Jens Axboe <ax...@kernel.dk>
> Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
> ---
> Greg I guess this can go through the drivercore tree?

Yes, I'll take it now, thanks.

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

Re: [PATCH] add POWER Virtual Management Channel driver

[Greg Kroah-Hartman]

On Wed, Feb 17, 2016 at 03:18:26PM -0600, Steven Royer wrote:
> On 2016-02-16 16:18, Greg Kroah-Hartman wrote:
> >On Tue, Feb 16, 2016 at 02:43:13PM -0600, Steven Royer wrote:
> >>From: Steven Royer <sero...@us.ibm.com>
> >>
> >>The ibmvmc driver is a device driver for the POWER Virtual Management
> >>Channel virtual adapter on the PowerVM platform.  It is used to
> >>communicate with the hypervisor for virtualization management.  It
> >>provides both request/response and asynchronous message support through
> >>the /dev/ibmvmc node.
> >
> >What is the protocol for that device node?
> The protocol is not currently published.  I am pushing on getting it
> published, but that process will take time.  If you have a PowerVM system
> with NovaLink, it would not be hard to reverse engineer it...  If you don't
> have a PowerVM system, then this driver isn't interesting anyway...

You can't just expect us to review this code without at least having a
clue as to how it is supposed to work?

> >Where is the documentation here?  Why does this have to be a character
> >device?  Why can't it fit in with other drivers of this type?
> This is a character device for historical reasons.  The short version is
> that this driver is a clean-room rewrite of an AIX driver which made it a
> character device.  The user space application was ported from AIX to Linux
> and it is convenient to have the AIX and Linux drivers match behavior where
> possible.

Note that we don't let random userspace applications dictate kernel api
decisions, please make the best choice for this interface without being
influenced by AIX.

> >>+/*
> >>+ * IBM Power Systems Virtual Management Channel Support.
> >>+ *
> >>+ * Copyright (c) 2004, 2016 IBM Corp.
> >>+ *   Dave Engebretsen engeb...@us.ibm.com
> >>+ *   Steven Royer sero...@linux.vnet.ibm.com
> >>+ *   Adam Reznechek adrez...@linux.vnet.ibm.com
> >>+ *
> >>+ * This program is free software; you can redistribute it and/or
> >>+ * modify it under the terms of the GNU General Public License
> >>+ * as published by the Free Software Foundation; either version 2
> >>+ * of the License, or (at your option) any later version.
> >
> >I have to ask, but do you really mean "or any later version"?
> This actually matches closely to other similar PowerVM virtual device
> drivers, like ibmvscsi or ibmveth.

That did not answer the question, picking a license in a cargo-cult
manner is not a wise decision :(

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