Re: converting Documentation/security/* to .rst

[Daniel Vetter]

On Wed, May 3, 2017 at 11:42 PM, Jonathan Corbet  wrote:
> On Mon, 1 May 2017 09:31:55 -0700
> Kees Cook  wrote:
>
>> > The real question would be one of organization.  Most of the security
>> > stuff looks like it properly belongs in the admin guide, but that's not
>> > universally the case.
>>
>> Are the index area "purposes" documented anywhere? The admin guide
>> seems to cover things outside of "administration" (like reporting
>> security bugs, which is a developer/researcher activity usually),
>> There's already a top-level "security documentation" with some TPM
>> stuff in it.
>
> They aren't really documented beyond what they, themselves, contain.  What
> you're seeing is the beginning of an effort to bring some order to the
> Documentation/ mess.  One of the biggest problems, IMO, is the lack of any
> sort of audience targeting.  We have lots of different kinds of people
> reading (we hope!) the docs, and they have to wade through a lot of
> irrelevant stuff.
>
> So we've set up guides for administrators, for kernel developers, and for
> user-space developers (the last just landing in 4.12).  There will never be
> a perfect spot for every document, but I hope we can create something
> that's more useful in the end.

Uuuhh... we might have torpedoed your efforts already in
Documenation/gpu/ Almost everything in there is for kernel developers
(gpu driver developers specifically), except we started to document
certain quirks and issues about the drm uapi in
Documentation/gpu/drm-uapi.rst. Much of that is again aimed at driver
developers (they need to implement the semantics correctly after all),
but it's also useful for userspace developers. And it might grow in
the future to include more.

How should we organize this? I admit that I'd like to keep it in
Documentation/gpu/ (because it is primarily aimed at kernel devs), but
at least linking it somewhere else might be useful?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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

[Resend][PATCH] cpufreq: intel_pstate: Document the current behavior and user interface

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Add a document describing the current behavior and user space
interface of the intel_pstate driver in the RST format and
drop the existing outdated intel_pstate.txt document.

Also update admin-guide/pm/cpufreq.rst with proper RST references
to the new intel_pstate.rst document.

Signed-off-by: Rafael J. Wysocki 
---

Hi Jon,

All of the dependencies for this patch have been merged, so I can route it
through the PM tree.

Please let me know if you prefer to take it into the documentation tree instead.

Thanks,
Rafael


---
 Documentation/admin-guide/pm/cpufreq.rst  |   19 
 Documentation/admin-guide/pm/index.rst|1 
 Documentation/admin-guide/pm/intel_pstate.rst |  755 ++
 Documentation/cpu-freq/intel-pstate.txt   |  281 -
 4 files changed, 766 insertions(+), 290 deletions(-)

Index: linux-pm/Documentation/admin-guide/pm/index.rst
===
--- linux-pm.orig/Documentation/admin-guide/pm/index.rst
+++ linux-pm/Documentation/admin-guide/pm/index.rst
@@ -6,6 +6,7 @@ Power Management
:maxdepth: 2
 
cpufreq
+   intel_pstate
 
 .. only::  subproject and html
 
Index: linux-pm/Documentation/admin-guide/pm/intel_pstate.rst
===
--- /dev/null
+++ linux-pm/Documentation/admin-guide/pm/intel_pstate.rst
@@ -0,0 +1,755 @@
+===
+``intel_pstate`` CPU Performance Scaling Driver
+===
+
+::
+
+ Copyright (c) 2017 Intel Corp., Rafael J. Wysocki 
+
+
+General Information
+===
+
+``intel_pstate`` is a part of the
+:doc:`CPU performance scaling subsystem ` in the Linux kernel
+(``CPUFreq``).  It is a scaling driver for the Sandy Bridge and later
+generations of Intel processors.  Note, however, that some of those processors
+may not be supported.  [To understand ``intel_pstate`` it is necessary to know
+how ``CPUFreq`` works in general, so this is the time to read :doc:`cpufreq` if
+you have not done that yet.]
+
+For the processors supported by ``intel_pstate``, the P-state concept is 
broader
+than just an operating frequency or an operating performance point (see the
+`LinuxCon Europe 2015 presentation by Kristen Accardi `_ for more
+information about that).  For this reason, the representation of P-states used
+by ``intel_pstate`` internally follows the hardware specification (for details
+refer to `Intel® 64 and IA-32 Architectures Software Developer’s Manual
+Volume 3: System Programming Guide `_).  However, the ``CPUFreq`` core
+uses frequencies for identifying operating performance points of CPUs and
+frequencies are involved in the user space interface exposed by it, so
+``intel_pstate`` maps its internal representation of P-states to frequencies 
too
+(fortunately, that mapping is unambiguous).  At the same time, it would not be
+practical for ``intel_pstate`` to supply the ``CPUFreq`` core with a table of
+available frequencies due to the possible size of it, so the driver does not do
+that.  Some functionality of the core is limited by that.
+
+Since the hardware P-state selection interface used by ``intel_pstate`` is
+available at the logical CPU level, the driver always works with individual
+CPUs.  Consequently, if ``intel_pstate`` is in use, every ``CPUFreq`` policy
+object corresponds to one logical CPU and ``CPUFreq`` policies are effectively
+equivalent to CPUs.  In particular, this means that they become "inactive" 
every
+time the corresponding CPU is taken offline and need to be re-initialized when
+it goes back online.
+
+``intel_pstate`` is not modular, so it cannot be unloaded, which means that the
+only way to pass early-configuration-time parameters to it is via the kernel
+command line.  However, its configuration can be adjusted via ``sysfs`` to a
+great extent.  In some configurations it even is possible to unregister it via
+``sysfs`` which allows another ``CPUFreq`` scaling driver to be loaded and
+registered (see `below `_).
+
+
+Operation Modes
+===
+
+``intel_pstate`` can operate in three different modes: in the active mode with
+or without hardware-managed P-states support and in the passive mode.  Which of
+them will be in effect depends on what kernel command line options are used and
+on the capabilities of the processor.
+
+Active Mode
+---
+
+This is the default operation mode of ``intel_pstate``.  If it works in this
+mode, the ``scaling_driver`` policy attribute in ``sysfs`` for all ``CPUFreq``
+policies contains the string "intel_pstate".
+
+In this mode the driver bypasses the scaling governors layer of ``CPUFreq`` and
+provides its own scaling algorithms for P-state selection.  Those algorithms
+can be applied to ``CPUFreq`` policies in the same way as generic scaling

Re: [PATCH v2 03/10] pinctrl: sunxi: add A20 support to A10 driver

[Maxime Ripard]

On Thu, May 04, 2017 at 10:45:11PM +0800, Icenowy Zheng wrote:
> 
> 
> 于 2017年5月4日 GMT+08:00 下午10:41:52, Maxime Ripard 
>  写到:
> >On Thu, May 04, 2017 at 10:03:26PM +0800, Icenowy Zheng wrote:
> >> 
> >> 
> >> 于 2017年5月4日 GMT+08:00 下午10:02:20, Maxime Ripard
> > 写到:
> >> >On Thu, May 04, 2017 at 09:49:59PM +0800, Icenowy Zheng wrote:
> >> >>  static const struct of_device_id sun4i_a10_pinctrl_match[] = {
> >> >> -   { .compatible = "allwinner,sun4i-a10-pinctrl", },
> >> >> +   {
> >> >> +   .compatible = "allwinner,sun4i-a10-pinctrl",
> >> >> +   .data = (void *)PINCTRL_SUN4I_A10
> >> >> +   },
> >> >> +   {
> >> >> +   .compatible = "allwinner,sun7i-a20-pinctrl",
> >> >> +   .data = (void *)PINCTRL_SUN7I_A20
> >> >> +   },
> >> >> {}
> >> >>  };
> >> >
> >> >This means you're going to have two drivers probing for the same
> >> >device: this driver, and the old one. This is not ok, and probably
> >> >introduces some corner cases.
> >> 
> >> The A20 driver is dropped in the next commit.
> >
> >Yes, and that is an issue for bisectability. Anyone that will checkout
> >between those two commits will have a broken kernel, and that is not
> >ok. Any commit should be in a working state.
> 
> Squash them together?

I would simply remove the A20's def_bool in that patch.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH v5 13/32] x86/boot/e820: Add support to determine the E820 type of an address

[Borislav Petkov]

On Tue, Apr 18, 2017 at 04:18:31PM -0500, Tom Lendacky wrote:
> Add a function that will return the E820 type associated with an address
> range.

...

> @@ -110,9 +111,28 @@ bool __init e820__mapped_all(u64 start, u64 end, enum 
> e820_type type)
>* coverage of the desired range exists:
>*/
>   if (start >= end)
> - return 1;
> + return entry;
>   }
> - return 0;
> +
> + return NULL;
> +}
> +
> +/*
> + * This function checks if the entire range  is mapped with type.
> + */
> +bool __init e820__mapped_all(u64 start, u64 end, enum e820_type type)
> +{
> + return __e820__mapped_all(start, end, type) ? 1 : 0;

return !!__e820__mapped_all(start, end, type);

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
--
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/3] perf: xgene: Add support for SoC PMU version 3

[Hoan Tran]

Ping!

Thanks
Hoan

On Thu, Apr 13, 2017 at 10:50 AM, Hoan Tran  wrote:
> Hi All,
>
> Do you have any comments on this patch set?
>
> Thanks
> Hoan
>
> On Mon, Apr 3, 2017 at 9:47 AM, Hoan Tran  wrote:
>>
>> This patch set adds support for SoC-wide (AKA uncore) Performance
>> Monitoring
>> Unit version 3.
>>
>> It can support up to
>>  - 2 IOB PMU instances
>>  - 8 L3C PMU instances
>>  - 2 MCB PMU instances
>>  - 8 MCU PMU instances
>>
>> v2:
>>  * Split into separate patches
>>  * Use the function pointers for the PMU leaf functions
>>  * Parse PMU subnode by the match table
>>  * Dont allow user change agent id by config1 for SoC PMU v3
>>
>> Hoan Tran (3):
>>   perf: xgene: Parse PMU subnode from the match table
>>   perf: xgene: Move PMU leaf functions into function pointer structure
>>   perf: xgene: Add support for SoC PMU version 3
>>
>>  drivers/perf/xgene_pmu.c | 695
>> +--
>>  1 file changed, 619 insertions(+), 76 deletions(-)
>>
>> --
>> 1.9.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 v8 5/7] coresight: add support for CPU debug module

[Mathieu Poirier]

On 5 May 2017 at 09:04, Sudeep Holla  wrote:
>
>
> On 05/05/17 15:48, Mathieu Poirier wrote:
>> On Fri, May 05, 2017 at 02:55:17PM +0100, Sudeep Holla wrote:
>
> [...]
>
>>>
>>> Just curious as why this is not registered under coresight bus using
>>> coresight_register ? It would be good to group all the coresight devices
>>> under that bus if possible.
>>
>> The only thing this driver has in common with the coresight framework is the
>> name, everything else is completely different.  Coupling them together 
>> (because
>> of the name) would introduce a lot of hacks and make the code unintelligible.
>>
>
> I guessed so from the quick glance at it as it needs descriptors with
> notion of source, sink and links to register. However I felt odd to not
> group under the same "coresight" bus. As someone with least knowledge
> on coresight, I would check under "sys/bus/coresight" to check available
> devices on the system.

2 years ago when implementing the coresight framework, using
"coresight" sounded like a logical choice but in hindsight it probably
should have been something like coresight-hat (HW Assisted Tracing).
That would have been a better representation of the reality, i.e the
term "coresight" being an umbrella for many kind of technology.  Leo
has done the right thing here with "coresight-cpu-debug".

>
> Anyways that's just my thoughts though I agree with you. It may need
> more refactoring to support that and it will look hackish if we try to
> do that with the code as it stands.
>
> --
> Regards,
> Sudeep
--
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 v8 5/7] coresight: add support for CPU debug module

[Sudeep Holla]

On 05/05/17 15:48, Mathieu Poirier wrote:
> On Fri, May 05, 2017 at 02:55:17PM +0100, Sudeep Holla wrote:

[...]

>>
>> Just curious as why this is not registered under coresight bus using
>> coresight_register ? It would be good to group all the coresight devices
>> under that bus if possible.
> 
> The only thing this driver has in common with the coresight framework is the
> name, everything else is completely different.  Coupling them together 
> (because
> of the name) would introduce a lot of hacks and make the code unintelligible. 
> 

I guessed so from the quick glance at it as it needs descriptors with
notion of source, sink and links to register. However I felt odd to not
group under the same "coresight" bus. As someone with least knowledge
on coresight, I would check under "sys/bus/coresight" to check available
devices on the system.

Anyways that's just my thoughts though I agree with you. It may need
more refactoring to support that and it will look hackish if we try to
do that with the code as it stands.

-- 
Regards,
Sudeep
--
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 v8 5/7] coresight: add support for CPU debug module

[Mathieu Poirier]

On Fri, May 05, 2017 at 02:55:17PM +0100, Sudeep Holla wrote:
> 
> 
> On 02/05/17 11:08, Leo Yan wrote:
> > Coresight includes debug module and usually the module connects with CPU
> > debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has
> > description for related info in "Part H: External Debug".
> > 
> > Chapter H7 "The Sample-based Profiling Extension" introduces several
> > sampling registers, e.g. we can check program counter value with
> > combined CPU exception level, secure state, etc. So this is helpful for
> > analysis CPU lockup scenarios, e.g. if one CPU has run into infinite
> > loop with IRQ disabled. In this case the CPU cannot switch context and
> > handle any interrupt (including IPIs), as the result it cannot handle
> > SMP call for stack dump.
> > 
> > This patch is to enable coresight debug module, so firstly this driver
> > is to bind apb clock for debug module and this is to ensure the debug
> > module can be accessed from program or external debugger. And the driver
> > uses sample-based registers for debug purpose, e.g. when system triggers
> > panic, the driver will dump program counter and combined context
> > registers (EDCIDSR, EDVIDSR); by parsing context registers so can
> > quickly get to know CPU secure state, exception level, etc.
> > 
> > Some of the debug module registers are located in CPU power domain, so
> > this requires the CPU power domain stays on when access related debug
> > registers, but the power management for CPU power domain is quite
> > dependent on SoC integration for power management. For the platforms
> > which with sane power controller implementations, this driver follows
> > the method to set EDPRCR to try to pull the CPU out of low power state
> > and then set 'no power down request' bit so the CPU has no chance to
> > lose power.
> > 
> > If the SoC has not followed up this design well for power management
> > controller, the user should use the command line parameter or sysfs
> > to constrain all or partial idle states to ensure the CPU power
> > domain is enabled and access coresight CPU debug component safely.
> > 
> > Signed-off-by: Leo Yan 
> > ---
> >  drivers/hwtracing/coresight/Kconfig   |  14 +
> >  drivers/hwtracing/coresight/Makefile  |   1 +
> >  drivers/hwtracing/coresight/coresight-cpu-debug.c | 670 
> > ++
> >  3 files changed, 685 insertions(+)
> >  create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c
> > 
> > diff --git a/drivers/hwtracing/coresight/Kconfig 
> > b/drivers/hwtracing/coresight/Kconfig
> > index 130cb21..8d55d6d 100644
> > --- a/drivers/hwtracing/coresight/Kconfig
> > +++ b/drivers/hwtracing/coresight/Kconfig
> > @@ -89,4 +89,18 @@ config CORESIGHT_STM
> >   logging useful software events or data coming from various entities
> >   in the system, possibly running different OSs
> >  
> > +config CORESIGHT_CPU_DEBUG
> > +   tristate "CoreSight CPU Debug driver"
> > +   depends on ARM || ARM64
> > +   depends on DEBUG_FS
> > +   help
> > + This driver provides support for coresight debugging module. This
> > + is primarily used to dump sample-based profiling registers when
> > + system triggers panic, the driver will parse context registers so
> > + can quickly get to know program counter (PC), secure state,
> > + exception level, etc. Before use debugging functionality, platform
> > + needs to ensure the clock domain and power domain are enabled
> > + properly, please refer Documentation/trace/coresight-cpu-debug.txt
> > + for detailed description and the example for usage.
> > +
> >  endif
> > diff --git a/drivers/hwtracing/coresight/Makefile 
> > b/drivers/hwtracing/coresight/Makefile
> > index af480d9..433d590 100644
> > --- a/drivers/hwtracing/coresight/Makefile
> > +++ b/drivers/hwtracing/coresight/Makefile
> > @@ -16,3 +16,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o 
> > \
> > coresight-etm4x-sysfs.o
> >  obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
> >  obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
> > +obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
> > diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c 
> > b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> > new file mode 100644
> > index 000..b77456d
> > --- /dev/null
> > +++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> 
> [...]
> 
> > +static int debug_probe(struct amba_device *adev, const struct amba_id *id)
> > +{
> > +   void __iomem *base;
> > +   struct device *dev = >dev;
> > +   struct debug_drvdata *drvdata;
> > +   struct resource *res = >res;
> > +   struct device_node *np = adev->dev.of_node;
> > +   int ret;
> > +
> > +   drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> > +   if (!drvdata)
> > +   return -ENOMEM;
> > +
> > +   drvdata->cpu = np ? of_coresight_get_cpu(np) 

Re: [PATCH v8 5/7] coresight: add support for CPU debug module

[Sudeep Holla]

On 02/05/17 11:08, Leo Yan wrote:
> Coresight includes debug module and usually the module connects with CPU
> debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has
> description for related info in "Part H: External Debug".
> 
> Chapter H7 "The Sample-based Profiling Extension" introduces several
> sampling registers, e.g. we can check program counter value with
> combined CPU exception level, secure state, etc. So this is helpful for
> analysis CPU lockup scenarios, e.g. if one CPU has run into infinite
> loop with IRQ disabled. In this case the CPU cannot switch context and
> handle any interrupt (including IPIs), as the result it cannot handle
> SMP call for stack dump.
> 
> This patch is to enable coresight debug module, so firstly this driver
> is to bind apb clock for debug module and this is to ensure the debug
> module can be accessed from program or external debugger. And the driver
> uses sample-based registers for debug purpose, e.g. when system triggers
> panic, the driver will dump program counter and combined context
> registers (EDCIDSR, EDVIDSR); by parsing context registers so can
> quickly get to know CPU secure state, exception level, etc.
> 
> Some of the debug module registers are located in CPU power domain, so
> this requires the CPU power domain stays on when access related debug
> registers, but the power management for CPU power domain is quite
> dependent on SoC integration for power management. For the platforms
> which with sane power controller implementations, this driver follows
> the method to set EDPRCR to try to pull the CPU out of low power state
> and then set 'no power down request' bit so the CPU has no chance to
> lose power.
> 
> If the SoC has not followed up this design well for power management
> controller, the user should use the command line parameter or sysfs
> to constrain all or partial idle states to ensure the CPU power
> domain is enabled and access coresight CPU debug component safely.
> 
> Signed-off-by: Leo Yan 
> ---
>  drivers/hwtracing/coresight/Kconfig   |  14 +
>  drivers/hwtracing/coresight/Makefile  |   1 +
>  drivers/hwtracing/coresight/coresight-cpu-debug.c | 670 
> ++
>  3 files changed, 685 insertions(+)
>  create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c
> 
> diff --git a/drivers/hwtracing/coresight/Kconfig 
> b/drivers/hwtracing/coresight/Kconfig
> index 130cb21..8d55d6d 100644
> --- a/drivers/hwtracing/coresight/Kconfig
> +++ b/drivers/hwtracing/coresight/Kconfig
> @@ -89,4 +89,18 @@ config CORESIGHT_STM
> logging useful software events or data coming from various entities
> in the system, possibly running different OSs
>  
> +config CORESIGHT_CPU_DEBUG
> + tristate "CoreSight CPU Debug driver"
> + depends on ARM || ARM64
> + depends on DEBUG_FS
> + help
> +   This driver provides support for coresight debugging module. This
> +   is primarily used to dump sample-based profiling registers when
> +   system triggers panic, the driver will parse context registers so
> +   can quickly get to know program counter (PC), secure state,
> +   exception level, etc. Before use debugging functionality, platform
> +   needs to ensure the clock domain and power domain are enabled
> +   properly, please refer Documentation/trace/coresight-cpu-debug.txt
> +   for detailed description and the example for usage.
> +
>  endif
> diff --git a/drivers/hwtracing/coresight/Makefile 
> b/drivers/hwtracing/coresight/Makefile
> index af480d9..433d590 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
>   coresight-etm4x-sysfs.o
>  obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
>  obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
> +obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
> diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c 
> b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> new file mode 100644
> index 000..b77456d
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c

[...]

> +static int debug_probe(struct amba_device *adev, const struct amba_id *id)
> +{
> + void __iomem *base;
> + struct device *dev = >dev;
> + struct debug_drvdata *drvdata;
> + struct resource *res = >res;
> + struct device_node *np = adev->dev.of_node;
> + int ret;
> +
> + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> + if (!drvdata)
> + return -ENOMEM;
> +
> + drvdata->cpu = np ? of_coresight_get_cpu(np) : 0;
> + if (per_cpu(debug_drvdata, drvdata->cpu)) {
> + dev_err(dev, "CPU%d drvdata has been initialized, "
> + "may be caused by binding wrong CPU node in the DT\n",
> + 

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

[Peter Rosin]

On 2017-04-18 12:59, Peter Rosin wrote:
> On 2017-04-18 10:51, Greg Kroah-Hartman wrote:
>> On Thu, Apr 13, 2017 at 06:43:07PM +0200, Peter Rosin wrote:
>>> +/**
>>> + * devm_mux_chip_unregister() - Resource-managed version 
>>> mux_chip_unregister().
>>> + * @dev: The device that originally registered the mux-chip.
>>> + * @mux_chip: The mux-chip to unregister.
>>> + *
>>> + * See mux_chip_unregister() for more details.
>>> + *
>>> + * Note that you do not normally need to call this function.
>>
>> Odd, then why is it exported???
> 
> You normally don't call the devm_foo_{free,release,unregister,etc} functions.
> The intention is of course that the resourse cleans up automatically. But 
> there
> are no cases where the manual clean up is not available, at least not that I 
> can
> find?

I had a second look and there are of course plenty of examples of missing clean 
up
versions for devm function. I simply hadn't looked very hard at all.

So, for v15 I intend to remove all of devm_mux_chip_unregister, 
devm_mux_chip_free
and devm_mux_control_put. They are all just sitting there with no callers. And 
the
mux-mmio/video-mux drivers by Philipp Zabel that build on top of this series 
don't
need them either. Besides, easy to resurrect if needed...

I will do v15 with the above, the change from mutex to semaphore for locking the
mux controller state [1] and a few small documentation improvements. That will 
be
rebased onto v4.12-rc1 and sent in 10 days or so, or whenever v4.12-rc1 is out.

Meanwhile, what I currently intend for v15 but based on v4.11 is available from
https://gitlab.com/peda-linux/mux.git in the "mux" branch.

Cheers,
peda

[1] https://lkml.org/lkml/2017/4/25/411
--
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