[PATCH V2 2/6] stm class: adds a loop to extract the first valid STM device name
The node name of STM master management policy is a concatenation of an
STM device name to which this policy applies and following an arbitrary
string, these two strings are concatenated with a dot.
This patch adds a loop for extracting the STM device name when an
arbitrary number of dot(s) are found in this STM device name.
Signed-off-by: Chunyan Zhang
---
drivers/hwtracing/stm/policy.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/hwtracing/stm/policy.c b/drivers/hwtracing/stm/policy.c
index 11ab6d0..691686e 100644
--- a/drivers/hwtracing/stm/policy.c
+++ b/drivers/hwtracing/stm/policy.c
@@ -321,21 +321,26 @@ stp_policies_make(struct config_group *group, const char
*name)
/*
* node must look like ., where
* is the name of an existing stm device and
-* is an arbitrary string
+* is an arbitrary string, when an arbitrary
+* number of dot(s) are found in the , the
+* first matched STM device name would be extracted.
*/
- p = strchr(devname, '.');
- if (!p) {
- kfree(devname);
- return ERR_PTR(-EINVAL);
- }
+ for (p = devname; ; p++) {
+ p = strchr(p, '.');
+ if (!p) {
+ kfree(devname);
+ return ERR_PTR(-EINVAL);
+ }
- *p++ = '\0';
+ *p = '\0';
- stm = stm_find_device(devname);
- kfree(devname);
+ stm = stm_find_device(devname);
+ if (stm)
+ break;
+ *p = '.';
+ }
- if (!stm)
- return ERR_PTR(-ENODEV);
+ kfree(devname);
mutex_lock(&stm->policy_mutex);
if (stm->policy) {
--
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
[PATCH v6 00/23] powerpc/8xx: Use large pages for RAM and IMMR and other improvments
The main purpose of this patchset is to dramatically reduce the time spent in DTLB miss handler. This is achieved by: 1/ Mapping RAM with 8M pages 2/ Mapping IMMR with a fixed 512K page On a live running system (VoIP gateway for Air Trafic Control), over a 10 minutes period (with 277s idle), we get 87 millions DTLB misses and approximatly 35 secondes are spent in DTLB handler. This represents 5.8% of the overall time and even 10.8% of the non-idle time. Among those 87 millions DTLB misses, 15% are on user addresses and 85% are on kernel addresses. And within the kernel addresses, 93% are on addresses from the linear address space and only 7% are on addresses from the virtual address space. Once the full patchset applied, the number of DTLB misses during the period is reduced to 11.8 millions for a duration of 5.8s, which represents 2% of the non-idle time. This patch also includes other miscellaneous improvements: 1/ Handling of CPU6 ERRATA directly in mtspr() C macro to reduce code specific to PPC8xx 2/ Rewrite of a few non critical ASM functions in C 3/ Removal of some unused items See related patches for details Main changes in v3: * Using fixmap instead of fix address for mapping IMMR Change in v4: * Fix of a wrong #if notified by kbuild robot in 07/23 Change in v5: * Removed use of pmd_val() as L-value * Adapted to match the new include files layout in Linux 4.5 Change in v6: * Removed remaining use of pmd_val() as L-value Christophe Leroy (23): powerpc/8xx: Save r3 all the time in DTLB miss handler powerpc/8xx: Map linear kernel RAM with 8M pages powerpc: Update documentation for noltlbs kernel parameter powerpc/8xx: move setup_initial_memory_limit() into 8xx_mmu.c powerpc32: Fix pte_offset_kernel() to return NULL for bad pages powerpc32: refactor x_mapped_by_bats() and x_mapped_by_tlbcam() together powerpc/8xx: Fix vaddr for IMMR early remap powerpc/8xx: Map IMMR area with 512k page at a fixed address powerpc/8xx: CONFIG_PIN_TLB unneeded for CONFIG_PPC_EARLY_DEBUG_CPM powerpc/8xx: map more RAM at startup when needed powerpc32: Remove useless/wrong MMU:setio progress message powerpc32: remove ioremap_base powerpc/8xx: Add missing SPRN defines into reg_8xx.h powerpc/8xx: Handle CPU6 ERRATA directly in mtspr() macro powerpc/8xx: remove special handling of CPU6 errata in set_dec() powerpc/8xx: rewrite set_context() in C powerpc/8xx: rewrite flush_instruction_cache() in C powerpc: add inline functions for cache related instructions powerpc32: Remove clear_pages() and define clear_page() inline powerpc32: move x_dcache_range() functions inline powerpc: Simplify test in __dma_sync() powerpc32: small optimisation in flush_icache_range() powerpc32: Remove one insn in mulhdu Documentation/kernel-parameters.txt | 2 +- arch/powerpc/Kconfig.debug | 1 - arch/powerpc/include/asm/cache.h | 19 +++ arch/powerpc/include/asm/cacheflush.h| 52 ++- arch/powerpc/include/asm/fixmap.h| 14 ++ arch/powerpc/include/asm/mmu-8xx.h | 4 +- arch/powerpc/include/asm/nohash/32/pgtable.h | 5 +- arch/powerpc/include/asm/page_32.h | 17 ++- arch/powerpc/include/asm/reg.h | 2 + arch/powerpc/include/asm/reg_8xx.h | 93 arch/powerpc/include/asm/time.h | 6 +- arch/powerpc/kernel/asm-offsets.c| 8 ++ arch/powerpc/kernel/head_8xx.S | 207 +-- arch/powerpc/kernel/misc_32.S| 107 ++ arch/powerpc/kernel/ppc_ksyms.c | 2 + arch/powerpc/kernel/ppc_ksyms_32.c | 1 - arch/powerpc/mm/8xx_mmu.c| 190 arch/powerpc/mm/Makefile | 1 + arch/powerpc/mm/dma-noncoherent.c| 2 +- arch/powerpc/mm/fsl_booke_mmu.c | 4 +- arch/powerpc/mm/init_32.c| 23 --- arch/powerpc/mm/mmu_decl.h | 34 +++-- arch/powerpc/mm/pgtable_32.c | 47 +- arch/powerpc/mm/ppc_mmu_32.c | 4 +- arch/powerpc/platforms/embedded6xx/mpc10x.h | 10 -- arch/powerpc/sysdev/cpm_common.c | 15 +- 26 files changed, 583 insertions(+), 287 deletions(-) create mode 100644 arch/powerpc/mm/8xx_mmu.c -- 2.1.0 -- 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 v6 03/23] powerpc: Update documentation for noltlbs kernel parameter
Now the noltlbs kernel parameter is also applicable to PPC8xx Signed-off-by: Christophe Leroy --- v2: no change v3: no change v4: no change v5: no change v6: no change Documentation/kernel-parameters.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 59e1515..c3e420b 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2592,7 +2592,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. nolapic_timer [X86-32,APIC] Do not use the local APIC timer. noltlbs [PPC] Do not use large page/tlb entries for kernel - lowmem mapping on PPC40x. + lowmem mapping on PPC40x and PPC8xx nomca [IA-64] Disable machine check abort handling -- 2.1.0 -- 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] mm: vmpressure: make vmpressure_window a tunable.
On Wed, Feb 3, 2016 at 5:19 PM, Johannes Weiner wrote: > > If the machine is just cleaning up use-once cache, frequent events > make no sense. And if the machine is struggling, the notifications > better be in time. > > That's hardly a tunable. It's a factor that needs constant dynamic > adjustment depending on VM state. The same state this mechanism is > supposed to report. If we can't get this right, how will userspace? I tend to agree for the "machine is struggling" case; notifications had better be in time so userspace can take the right action. But one prime use for the "low" notification level is maintaining cache levels, and in that scenario I can imagine the rate at which you want to receive notifications can be very application-dependent. For a bit more context, we'd like to use these events for implementing a user-space low memory killer in Android (and get rid of the one in staging). What we've found so far is that the "medium" level doesn't trigger as often as we'd like: by the time we get it the page cache may have been drained to such low levels that the device will have to fetch pretty much everything from flash on the next app launch. I think that's just the way the medium level was defined. The "low" level on the other hand fires events almost constantly, and we spend a lot of time waking up, looking at memory state, and then doing nothing. My first idea was to make the window size dependent on machine size; but my worry is that this will be somewhat specific to our use of these pressure events. Maybe on Android devices it's okay to generate events for every say 1% of main memory being scanned for reclaim, but how do we know this is a decent value for other uses? My other concern with changing the window size directly is that there may be existing users of the API which would suddenly get different behavior. One other way to maintain the cache levels may be to not actually look at vm pressure events, but to just look at the state of the system for every X bytes allocated. > > > A better approach here would be to 1) find a minimum window size that > makes us confident that there are no false positives - this is likely > to be based on machine size, maybe the low watermark? - and 2) limit > reporting of lower levels, so you're not flooded with ALLGOOD! events. > > VMPRESSURE_CRITICAL: report every vmpressure_win > VMPRESSURE_MEDIUM: report every vmpressure_win*2 > VMPRESSURE_LOW: report every vmpressure_win*4 > > Pick your favorite scaling factor here. I like this idea; I'm happy to come up with a window size and scaling factors that we think works well, and get your feedback on that. My only concern again would be that what works well for us may not work well for others. -- 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 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout panic support
Guenter Roeck wrote: Also, if panic is enabled, the timeout needs to be adjusted accordingly (to only panic after the entire timeout period has expired, not after half of it). We can not panic the system after timeout / 2. It's a debugging feature, not an actual watchdog timeout panic. That's why it's disabled by default. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation. -- 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 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout panic support
On 02/04/2016 05:48 AM, Timur Tabi wrote: Guenter Roeck wrote: Also, if panic is enabled, the timeout needs to be adjusted accordingly (to only panic after the entire timeout period has expired, not after half of it). We can not panic the system after timeout / 2. It's a debugging feature, not an actual watchdog timeout panic. That's why it's disabled by default. "* When the first stage(the half timeout) is reached, WS0 interrupt is * triggered, at this moment the second watch period starts; * In the WS0 interrupt routine, panic will be triggered for saving the * system context. * If the system is getting into trouble and cannot be reset by panic or * restart properly by the kdump kernel(if supported), then the second * stage (the timeout) will be reached, system will be reset by WS1." That doesn't sound like debugging to me. Guenter -- 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 4/5] Watchdog: introduce ARM SBSA watchdog driver
On 3 February 2016 at 10:18, wrote: > From: Fu Wei > > According to Server Base System Architecture (SBSA) specification, > the SBSA Generic Watchdog has two stage timeouts: the first signal (WS0) > is for alerting the system by interrupt, the second one (WS1) is a real > hardware reset. > > This patch initially implements a simple single stage watchdog driver: > when the timeout is reached, your system will be reset by the second > signal (WS1). > The first signal (WS0) is ignored in this driver. > > This driver bases on linux kernel watchdog framework, so it can get > timeout from module parameter and FDT at the driver init stage. > > Signed-off-by: Fu Wei > Reviewed-by: Graeme Gregory > Tested-by: Pratyush Anand > --- > drivers/watchdog/Kconfig | 17 +++ > drivers/watchdog/Makefile| 1 + > drivers/watchdog/sbsa_gwdt.c | 322 > +++ > 3 files changed, 340 insertions(+) > > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > index 4f0e7be..4ab1b05 100644 > --- a/drivers/watchdog/Kconfig > +++ b/drivers/watchdog/Kconfig > @@ -201,6 +201,23 @@ config ARM_SP805_WATCHDOG > ARM Primecell SP805 Watchdog timer. This will reboot your system > when > the timeout is reached. > > +config ARM_SBSA_WATCHDOG > + tristate "ARM SBSA Generic Watchdog" > + depends on ARM64 > + depends on ARM_ARCH_TIMER > + select WATCHDOG_CORE > + help > + ARM SBSA Generic Watchdog has two stage timeouts: > + the first signal (WS0) is for alerting the system by interrupt, > + the second one (WS1) is a real hardware reset. > + More details: ARM DEN0029B - Server Base System Architecture (SBSA) > + > + This is a simple single stage driver: when the timeout is reached, > + your system will be reset by WS1. The first signal (WS0) is ignored. > + > + To compile this driver as module, choose M here: The module > + will be called sbsa_gwdt. > + > config ASM9260_WATCHDOG > tristate "Alphascale ASM9260 watchdog" > depends on MACH_ASM9260 > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile > index f566753..f9826d4 100644 > --- a/drivers/watchdog/Makefile > +++ b/drivers/watchdog/Makefile > @@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o > > # ARM Architecture > obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o > +obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o > obj-$(CONFIG_ASM9260_WATCHDOG) += asm9260_wdt.o > obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o > obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o > diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c > new file mode 100644 > index 000..5a2dba3 > --- /dev/null > +++ b/drivers/watchdog/sbsa_gwdt.c > @@ -0,0 +1,322 @@ > +/* > + * SBSA(Server Base System Architecture) Generic Watchdog driver > + * > + * Copyright (c) 2015, Linaro Ltd. > + * Author: Fu Wei > + * Suravee Suthikulpanit > + * Al Stone > + * Timur Tabi > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License 2 as published > + * by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * This SBSA Generic watchdog driver is a single stage timeout version. > + * Since this watchdog timer has two stages, and each stage is determined > + * by WOR. So the timeout is (WOR * 2). > + * When first timeout is reached, WS0 is triggered, the interrupt > + * triggered by WS0 will be ignored, then the second watch period starts; > + * when second timeout is reached, then WS1 is triggered, system reset. > + * > + * More details about the hardware specification of this device: > + * ARM DEN0029B - Server Base System Architecture (SBSA) > + * > + * SBSA GWDT: |WOR---WS0WOR---WS1 > + *|timeoutreset > + * > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* SBSA Generic Watchdog register definitions */ > +/* refresh frame */ > +#define SBSA_GWDT_WRR 0x000 > + > +/* control frame */ > +#define SBSA_GWDT_WCS 0x000 > +#define SBSA_GWDT_WOR 0x008 > +#define SBSA_GWDT_WCV 0x010 > + > +/* refresh/control frame */ > +#define SBSA_GWDT_W_IIDR 0xfcc > +#define SBSA_GWDT_IDR 0xfd0 > + > +/* Watchdog Control and Status Register */ > +#define SBSA_GWDT_WCS_EN BIT(0) > +#define SBSA_GWDT_WCS_WS0
Re: [PATCH v10 4/5] Watchdog: introduce ARM SBSA watchdog driver
On Thu, Feb 04, 2016 at 01:18:42AM +0800, fu@linaro.org wrote:
> +static int sbsa_gwdt_keepalive(struct watchdog_device *wdd)
> +{
> + struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
> +
> + /*
> + * Writing WRR for an explicit watchdog refresh.
> + * You can write anyting(like 0xc0ffee).
> + */
> + writel(0xc0ffee, gwdt->refresh_base + SBSA_GWDT_WRR);
> +
> + return 0;
> +}
You might get in trouble for that. 0xd09f00d is probably less poisonous.
http://www.petpoisonhelpline.com/poison/caffeine/
Will
--
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 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout panic support
On 3 February 2016 at 10:18, wrote:
> From: Fu Wei
>
> This patch registers the WS0 interrupt routine to trigger panic,
> when the watchdog reachs the first stage (the half timeout).
> This function can help administrator to backup the system context
> info by panic console output or kdump (if supported), once system
> goes wrong (doesn't feed the watchdog in the half timeout).
>
> User also can skip panic by setting panic_enabled (module parameter) as 0
>
> Signed-off-by: Fu Wei
> ---
> Documentation/watchdog/watchdog-parameters.txt | 1 +
> drivers/watchdog/Kconfig | 10 +
> drivers/watchdog/sbsa_gwdt.c | 54
> +++---
> 3 files changed, 60 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/watchdog/watchdog-parameters.txt
> b/Documentation/watchdog/watchdog-parameters.txt
> index 300eb4d..31641e2 100644
> --- a/Documentation/watchdog/watchdog-parameters.txt
> +++ b/Documentation/watchdog/watchdog-parameters.txt
> @@ -286,6 +286,7 @@ nowayout: Watchdog cannot be stopped once started
> -
> sbsa_gwdt:
> timeout: Watchdog timeout in seconds. (default 20s)
> +panic_enabled: Enable panic at half timeout. (default=true)
> nowayout: Watchdog cannot be stopped once started
> (default=kernel config parameter)
> -
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 4ab1b05..42adfdf 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -218,6 +218,16 @@ config ARM_SBSA_WATCHDOG
> To compile this driver as module, choose M here: The module
> will be called sbsa_gwdt.
>
> +config ARM_SBSA_WATCHDOG_PANIC
> + bool "ARM SBSA Generic Watchdog triggers panic at the half timeout"
> + depends on ARM_SBSA_WATCHDOG
> + help
> + ARM SBSA Generic Watchdog will trigger panic in the first signal
> + (WS0) interrupt routine when the half timeout is reached.
> + This function can help administrator to backup the system context
> + info by panic console output or kdump (if supported).
> + But user can skip panic by setting moduleparam panic_enabled as 0.
> +
> config ASM9260_WATCHDOG
> tristate "Alphascale ASM9260 watchdog"
> depends on MACH_ASM9260
> diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
> index 5a2dba3..d18cf37 100644
> --- a/drivers/watchdog/sbsa_gwdt.c
> +++ b/drivers/watchdog/sbsa_gwdt.c
> @@ -16,18 +16,22 @@
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> * GNU General Public License for more details.
> *
> - * This SBSA Generic watchdog driver is a single stage timeout version.
> + * This SBSA Generic watchdog driver is a two stages version.
> * Since this watchdog timer has two stages, and each stage is determined
> * by WOR. So the timeout is (WOR * 2).
> - * When first timeout is reached, WS0 is triggered, the interrupt
> - * triggered by WS0 will be ignored, then the second watch period starts;
> - * when second timeout is reached, then WS1 is triggered, system reset.
> + * When the first stage(the half timeout) is reached, WS0 interrupt is
> + * triggered, at this moment the second watch period starts;
> + * In the WS0 interrupt routine, panic will be triggered for saving the
> + * system context.
> + * If the system is getting into trouble and cannot be reset by panic or
> + * restart properly by the kdump kernel(if supported), then the second
> + * stage (the timeout) will be reached, system will be reset by WS1.
> *
> * More details about the hardware specification of this device:
> * ARM DEN0029B - Server Base System Architecture (SBSA)
> *
> * SBSA GWDT: |WOR---WS0WOR---WS1
> - *|timeoutreset
> + *|--half_timeout--(panic)--half_timeout--reset
> *
> */
>
> @@ -84,6 +88,13 @@ MODULE_PARM_DESC(timeout,
> "Watchdog timeout in seconds. (>=0, default="
> __MODULE_STRING(DEFAULT_TIMEOUT) ")");
>
> +#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
> +static bool panic_enabled = true;
> +module_param(panic_enabled, bool, 0);
> +MODULE_PARM_DESC(panic_enabled,
> +"enable panic at half timeout. (default=true)");
> +#endif
> +
> static bool nowayout = WATCHDOG_NOWAYOUT;
> module_param(nowayout, bool, S_IRUGO);
> MODULE_PARM_DESC(nowayout,
> @@ -159,6 +170,16 @@ static int sbsa_gwdt_stop(struct watchdog_device *wdd)
> return 0;
> }
>
> +#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
> +static irqreturn_t sbsa_gwdt_interrupt(int irq, void *dev_id)
> +{
> + if (panic_enabled)
> + panic("SBSA Watchdog half timeout");
> +
> + return IRQ_HANDLED;
> +}
> +#endif
> +
> static struct watchdog_info sbsa_gwdt_info = {
> .identity = "SBSA Generic Watchdog",
> .options
Re: [PATCH v10 4/5] Watchdog: introduce ARM SBSA watchdog driver
Will Deacon wrote:
+static int sbsa_gwdt_keepalive(struct watchdog_device *wdd)
>+{
>+ struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
>+
>+ /*
>+ * Writing WRR for an explicit watchdog refresh.
>+ * You can write anyting(like 0xc0ffee).
>+ */
>+ writel(0xc0ffee, gwdt->refresh_base + SBSA_GWDT_WRR);
>+
>+ return 0;
>+}
You might get in trouble for that. 0xd09f00d is probably less poisonous.
http://www.petpoisonhelpline.com/poison/caffeine/
Any reason why we can't just keep it simple and write 0?
--
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 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout panic support
Mathieu Poirier wrote:
>+#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
>+ irq = platform_get_irq(pdev, 0);
>+ if (irq < 0) {
>+ dev_err(dev, "unable to get ws0 interrupt.\n");
>+ return irq;
>+ }
>+#endif
>+
Can't the driver revert to single stage mode if platform_get_irq()
fails? That way the value of 'irq' can be tested throughout the
_probe() function and the #ifdefs removed.
I like that idea. The same can be done with the devm_request_irq()
call. It should definitely still display a warning if the command-line
option is set but no interrupt is available.
--
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 4/5] Watchdog: introduce ARM SBSA watchdog driver
On 02/04/2016 08:37 AM, Timur Tabi wrote:
Will Deacon wrote:
+static int sbsa_gwdt_keepalive(struct watchdog_device *wdd)
>+{
>+struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
>+
>+/*
>+* Writing WRR for an explicit watchdog refresh.
>+* You can write anyting(like 0xc0ffee).
>+*/
>+writel(0xc0ffee, gwdt->refresh_base + SBSA_GWDT_WRR);
>+
>+return 0;
>+}
You might get in trouble for that. 0xd09f00d is probably less poisonous.
http://www.petpoisonhelpline.com/poison/caffeine/
Any reason why we can't just keep it simple and write 0?
+1
Guenter
--
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 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout panic support
On 02/04/2016 08:32 AM, Mathieu Poirier wrote:
On 3 February 2016 at 10:18, wrote:
From: Fu Wei
This patch registers the WS0 interrupt routine to trigger panic,
when the watchdog reachs the first stage (the half timeout).
This function can help administrator to backup the system context
info by panic console output or kdump (if supported), once system
goes wrong (doesn't feed the watchdog in the half timeout).
User also can skip panic by setting panic_enabled (module parameter) as 0
Signed-off-by: Fu Wei
---
Documentation/watchdog/watchdog-parameters.txt | 1 +
drivers/watchdog/Kconfig | 10 +
drivers/watchdog/sbsa_gwdt.c | 54 +++---
3 files changed, 60 insertions(+), 5 deletions(-)
diff --git a/Documentation/watchdog/watchdog-parameters.txt
b/Documentation/watchdog/watchdog-parameters.txt
index 300eb4d..31641e2 100644
--- a/Documentation/watchdog/watchdog-parameters.txt
+++ b/Documentation/watchdog/watchdog-parameters.txt
@@ -286,6 +286,7 @@ nowayout: Watchdog cannot be stopped once started
-
sbsa_gwdt:
timeout: Watchdog timeout in seconds. (default 20s)
+panic_enabled: Enable panic at half timeout. (default=true)
nowayout: Watchdog cannot be stopped once started
(default=kernel config parameter)
-
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 4ab1b05..42adfdf 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -218,6 +218,16 @@ config ARM_SBSA_WATCHDOG
To compile this driver as module, choose M here: The module
will be called sbsa_gwdt.
+config ARM_SBSA_WATCHDOG_PANIC
+ bool "ARM SBSA Generic Watchdog triggers panic at the half timeout"
+ depends on ARM_SBSA_WATCHDOG
+ help
+ ARM SBSA Generic Watchdog will trigger panic in the first signal
+ (WS0) interrupt routine when the half timeout is reached.
+ This function can help administrator to backup the system context
+ info by panic console output or kdump (if supported).
+ But user can skip panic by setting moduleparam panic_enabled as 0.
+
config ASM9260_WATCHDOG
tristate "Alphascale ASM9260 watchdog"
depends on MACH_ASM9260
diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
index 5a2dba3..d18cf37 100644
--- a/drivers/watchdog/sbsa_gwdt.c
+++ b/drivers/watchdog/sbsa_gwdt.c
@@ -16,18 +16,22 @@
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
- * This SBSA Generic watchdog driver is a single stage timeout version.
+ * This SBSA Generic watchdog driver is a two stages version.
* Since this watchdog timer has two stages, and each stage is determined
* by WOR. So the timeout is (WOR * 2).
- * When first timeout is reached, WS0 is triggered, the interrupt
- * triggered by WS0 will be ignored, then the second watch period starts;
- * when second timeout is reached, then WS1 is triggered, system reset.
+ * When the first stage(the half timeout) is reached, WS0 interrupt is
+ * triggered, at this moment the second watch period starts;
+ * In the WS0 interrupt routine, panic will be triggered for saving the
+ * system context.
+ * If the system is getting into trouble and cannot be reset by panic or
+ * restart properly by the kdump kernel(if supported), then the second
+ * stage (the timeout) will be reached, system will be reset by WS1.
*
* More details about the hardware specification of this device:
* ARM DEN0029B - Server Base System Architecture (SBSA)
*
* SBSA GWDT: |WOR---WS0WOR---WS1
- *|timeoutreset
+ *|--half_timeout--(panic)--half_timeout--reset
*
*/
@@ -84,6 +88,13 @@ MODULE_PARM_DESC(timeout,
"Watchdog timeout in seconds. (>=0, default="
__MODULE_STRING(DEFAULT_TIMEOUT) ")");
+#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
+static bool panic_enabled = true;
+module_param(panic_enabled, bool, 0);
+MODULE_PARM_DESC(panic_enabled,
+"enable panic at half timeout. (default=true)");
+#endif
+
static bool nowayout = WATCHDOG_NOWAYOUT;
module_param(nowayout, bool, S_IRUGO);
MODULE_PARM_DESC(nowayout,
@@ -159,6 +170,16 @@ static int sbsa_gwdt_stop(struct watchdog_device *wdd)
return 0;
}
+#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
+static irqreturn_t sbsa_gwdt_interrupt(int irq, void *dev_id)
+{
+ if (panic_enabled)
+ panic("SBSA Watchdog half timeout");
+
+ return IRQ_HANDLED;
+}
+#endif
+
static struct watchdog_info sbsa_gwdt_info = {
.identity = "SBSA Generic Watchdog",
.options= WDIOF_SETTIMEOUT |
@@ -186,6 +207,9 @@ static int sbsa_gwdt_probe(struct platform_device *pdev)
struct resource *res;
Re: [PATCH V2 2/6] stm class: adds a loop to extract the first valid STM device name
Chunyan Zhang writes:
I few comments below:
> The node name of STM master management policy is a concatenation of an
> STM device name to which this policy applies and following an arbitrary
> string, these two strings are concatenated with a dot.
This is true.
> This patch adds a loop for extracting the STM device name when an
> arbitrary number of dot(s) are found in this STM device name.
It's not very easy to tell what's going on here from this
description. The reader be left curious as to why an arbitrary number of
dots is a reason to run a loop. When in doubt, try to imagine as if
you're seeing this patch for the first time and ask yourself, does the
message give a clear explanation of what's going on in it.
> Signed-off-by: Chunyan Zhang
> ---
> drivers/hwtracing/stm/policy.c | 27 ---
> 1 file changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/hwtracing/stm/policy.c b/drivers/hwtracing/stm/policy.c
> index 11ab6d0..691686e 100644
> --- a/drivers/hwtracing/stm/policy.c
> +++ b/drivers/hwtracing/stm/policy.c
> @@ -321,21 +321,26 @@ stp_policies_make(struct config_group *group, const
> char *name)
> /*
>* node must look like ., where
>* is the name of an existing stm device and
> - * is an arbitrary string
> + * is an arbitrary string, when an arbitrary
> + * number of dot(s) are found in the , the
> + * first matched STM device name would be extracted.
>*/
This leaves room for a number of suspicious situations. What if both
"xyz" and "xyz.0" are stm devices, how would you create a policy for the
latter, for example?
The rules should be such that you can tell exactly what the intended stm
device is from a policy directory name, otherwise it's just asking for
trouble.
> - p = strchr(devname, '.');
> - if (!p) {
> - kfree(devname);
> - return ERR_PTR(-EINVAL);
> - }
> + for (p = devname; ; p++) {
> + p = strchr(p, '.');
> + if (!p) {
> + kfree(devname);
> + return ERR_PTR(-EINVAL);
> + }
>
> - *p++ = '\0';
> + *p = '\0';
>
> - stm = stm_find_device(devname);
> - kfree(devname);
> + stm = stm_find_device(devname);
> + if (stm)
> + break;
> + *p = '.';
> + }
>
> - if (!stm)
> - return ERR_PTR(-ENODEV);
> + kfree(devname);
In the existing code there is a clear distinction between -ENODEV, which
is to say "we didn't find the device" and -EINVAL, "directory name
breaks rules/is badly formatted". After the change, it's all -EINVAL,
which also becomes "we tried everything, sorry".
So, having said all that, does the following patch solve your problem:
>From 870dc5fefa5623c39552511d31e0fa0da984d581 Mon Sep 17 00:00:00 2001
From: Alexander Shishkin
Date: Thu, 4 Feb 2016 18:56:34 +0200
Subject: [PATCH] stm class: Support devices with multiple instances
By convention, the name of the stm policy directory in configfs consists of
the device name to which it applies and the actual policy name, separated
by a dot. Now, some devices already have dots in their names that separate
name of the actual device from its instance identifier. Such devices will
result in two (or more, who can tell) dots in the policy directory name.
Existing policy code, however, will treat the first dot as the one that
separates device name from policy name, therefore failing the above case.
This patch makes the last dot in the directory name be the separator, thus
prohibiting dots from being used in policy names.
Suggested-by: Chunyan Zhang
Signed-off-by: Alexander Shishkin
---
drivers/hwtracing/stm/policy.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/hwtracing/stm/policy.c b/drivers/hwtracing/stm/policy.c
index 94d3abfb73..1db189657b 100644
--- a/drivers/hwtracing/stm/policy.c
+++ b/drivers/hwtracing/stm/policy.c
@@ -332,10 +332,11 @@ stp_policies_make(struct config_group *group, const char
*name)
/*
* node must look like ., where
-* is the name of an existing stm device and
-* is an arbitrary string
+* is the name of an existing stm device; may
+* contain dots;
+* is an arbitrary string; may not contain dots
*/
- p = strchr(devname, '.');
+ p = strrchr(devname, '.');
if (!p) {
kfree(devname);
return ERR_PTR(-EINVAL);
--
2.7.0
--
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] mm: vmpressure: make vmpressure_window a tunable.
On Thu, Feb 04, 2016 at 12:18:34PM +0100, Martijn Coenen wrote: > I like this idea; I'm happy to come up with a window size and scaling > factors that we think works well, and get your feedback on that. My > only concern again would be that what works well for us may not work > well for others. Thanks for doing this. There is a good chance that this will work just fine for others as well, so I think it's preferable to speculatively change the implementation than adding ABI for potentially no reason. -- 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: module: s390: keep mod_arch_specific for livepatch modules
On Wed, Feb 03, 2016 at 08:37:52PM -0500, Jessica Yu wrote: > +++ Jessica Yu [03/02/16 20:11 -0500]: > >Livepatch needs to utilize the symbol information contained in the > >mod_arch_specific struct in order to be able to call the s390 > >apply_relocate_add() function to apply relocations. Keep a reference to > >syminfo if the module is a livepatch module. Remove the redundant vfree() > >in module_finalize() since module_arch_freeing_init() (which also frees > >those structures) is called in do_init_module(). If the module isn't a > >livepatch module, we free the structures in module_arch_freeing_init() as > >usual. > > > >Signed-off-by: Jessica Yu > >--- > >arch/s390/kernel/module.c | 7 +-- > >1 file changed, 5 insertions(+), 2 deletions(-) > > I must note that I have verified that the patchset boots on s390 and > that the sample livepatch module still works ...so that's good, but > not saying much since what we really want is to test the relocation > code. The kpatch build scripts however currently only support x86, so > the next step is for me to port the kpatch scripts to s390 before I > can really test this patchset. This in itself might take a while, so > in the meantime I'd like to just collect another round of comments and > feedback for v4. I haven't reviewed the code yet, but otherwise I'm thinking it would actually be fine to merge this patch set before testing with s390 relocations. They aren't implemented on s390 today anyway, so there can't be a regression if nobody is using it. -- Josh -- 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 v2] drm: Clean up drm Makefile
This patch cleans up the Makefile of drm root directory. Make core and device drivers configuration list sorted Alphabetically. Signed-off-by: Xinliang Liu Reviewed-by: Xinwei Kong Reviewed-by: Yifan Liu --- drivers/gpu/drm/Makefile | 102 --- 1 file changed, 52 insertions(+), 50 deletions(-) diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 61766dec6a8d..23e57948f68f 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -2,6 +2,9 @@ # Makefile for the drm device driver. This driver provides support for the # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. +CFLAGS_drm_trace_points.o := -I$(src) + +# core. Please keep this list sorted alphabetically drm-y := drm_auth.o drm_bufs.o drm_cache.o \ drm_context.o drm_dma.o \ drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \ @@ -13,64 +16,63 @@ drm-y := drm_auth.o drm_bufs.o drm_cache.o \ drm_trace_points.o drm_global.o drm_prime.o \ drm_rect.o drm_vma_manager.o drm_flip_work.o \ drm_modeset_lock.o drm_atomic.o drm_bridge.o - -drm-$(CONFIG_COMPAT) += drm_ioc32.o -drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o drm-$(CONFIG_PCI) += ati_pcigart.o -drm-$(CONFIG_DRM_PANEL) += drm_panel.o -drm-$(CONFIG_OF) += drm_of.o drm-$(CONFIG_AGP) += drm_agpsupport.o +drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o +drm-$(CONFIG_COMPAT) += drm_ioc32.o +drm-$(CONFIG_OF) += drm_of.o +drm-$(CONFIG_DRM_PANEL) += drm_panel.o +obj-$(CONFIG_DRM) += drm.o + +obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o -drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o - +drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o -CFLAGS_drm_trace_points.o := -I$(src) +obj-$(CONFIG_DRM_TTM) += ttm/ -obj-$(CONFIG_DRM) += drm.o -obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o -obj-$(CONFIG_DRM_TTM) += ttm/ -obj-$(CONFIG_DRM_TDFX) += tdfx/ -obj-$(CONFIG_DRM_R128) += r128/ -obj-$(CONFIG_HSA_AMD) += amd/amdkfd/ -obj-$(CONFIG_DRM_RADEON)+= radeon/ -obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/ -obj-$(CONFIG_DRM_MGA) += mga/ -obj-$(CONFIG_DRM_I810) += i810/ -obj-$(CONFIG_DRM_I915) += i915/ -obj-$(CONFIG_DRM_MGAG200) += mgag200/ -obj-$(CONFIG_DRM_VC4) += vc4/ -obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/ -obj-$(CONFIG_DRM_SIS) += sis/ -obj-$(CONFIG_DRM_SAVAGE)+= savage/ -obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/ -obj-$(CONFIG_DRM_VIA) +=via/ -obj-$(CONFIG_DRM_VGEM) += vgem/ -obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/ -obj-$(CONFIG_DRM_EXYNOS) +=exynos/ -obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/ -obj-$(CONFIG_DRM_GMA500) += gma500/ -obj-$(CONFIG_DRM_UDL) += udl/ -obj-$(CONFIG_DRM_AST) += ast/ -obj-$(CONFIG_DRM_ARMADA) += armada/ +# device drivers. Please keep this list sorted alphabetically +obj-$(CONFIG_HSA_AMD) += amd/amdkfd/ +obj-$(CONFIG_DRM_AMDGPU) += amd/amdgpu/ +obj-$(CONFIG_DRM_ARMADA) += armada/ +obj-$(CONFIG_DRM_AST) += ast/ obj-$(CONFIG_DRM_ATMEL_HLCDC) += atmel-hlcdc/ -obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/ -obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/ -obj-y += omapdrm/ -obj-y += tilcdc/ -obj-$(CONFIG_DRM_QXL) += qxl/ -obj-$(CONFIG_DRM_BOCHS) += bochs/ -obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio/ -obj-$(CONFIG_DRM_MSM) += msm/ -obj-$(CONFIG_DRM_TEGRA) += tegra/ -obj-$(CONFIG_DRM_STI) += sti/ -obj-$(CONFIG_DRM_IMX) += imx/ -obj-y += i2c/ -obj-y += panel/ -obj-y += bridge/ -obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/ -obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/ +obj-$(CONFIG_DRM_BOCHS)+= bochs/ +obj-y += bridge/ +obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/ +obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/ +obj-$(CONFIG_DRM_EXYNOS) += exynos/ +obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/ +obj-$(CONFIG_DRM_GMA500) += gma500/ +obj-y += i2c/ +obj-$(CONFIG_DRM_I810) += i810/ +obj-$(CONFIG_DRM_I915) += i915/ +obj-$(CONFIG_DRM_IMX) += imx/ +obj-$(CONFIG_DRM_MGA) += mga/ +obj-$(CONFIG_DRM_MGAG200) += mgag200/ +obj-$(CONFIG_DRM_MSM) += msm/ +obj-$(CONFIG_DRM_NOUVEAU) += nouveau/ +obj-y += omapdrm/ +obj-y += panel/ +obj-$(CONFIG_DRM_QXL) += qxl/ +obj-$(CONFIG_DRM_R128) += r128/ +obj-$(CONFIG_DRM_RADEON) += radeon/ +obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/ +obj-$(CONFIG_DRM_ROCKCHIP) += rockchip/ +obj-$(CONFIG_DRM_SAVAGE) += savage/ +obj-$(CONFIG_DRM_SHM
Re: [PATCH V2 2/6] stm class: adds a loop to extract the first valid STM device name
On Fri, Feb 5, 2016 at 1:30 AM, Alexander Shishkin
wrote:
> Chunyan Zhang writes:
>
> I few comments below:
>
>> The node name of STM master management policy is a concatenation of an
>> STM device name to which this policy applies and following an arbitrary
>> string, these two strings are concatenated with a dot.
>
> This is true.
>
>> This patch adds a loop for extracting the STM device name when an
>> arbitrary number of dot(s) are found in this STM device name.
>
> It's not very easy to tell what's going on here from this
> description. The reader be left curious as to why an arbitrary number of
> dots is a reason to run a loop. When in doubt, try to imagine as if
> you're seeing this patch for the first time and ask yourself, does the
> message give a clear explanation of what's going on in it.
>
>> Signed-off-by: Chunyan Zhang
>> ---
>> drivers/hwtracing/stm/policy.c | 27 ---
>> 1 file changed, 16 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/hwtracing/stm/policy.c b/drivers/hwtracing/stm/policy.c
>> index 11ab6d0..691686e 100644
>> --- a/drivers/hwtracing/stm/policy.c
>> +++ b/drivers/hwtracing/stm/policy.c
>> @@ -321,21 +321,26 @@ stp_policies_make(struct config_group *group, const
>> char *name)
>> /*
>>* node must look like ., where
>>* is the name of an existing stm device and
>> - * is an arbitrary string
>> + * is an arbitrary string, when an arbitrary
>> + * number of dot(s) are found in the , the
>> + * first matched STM device name would be extracted.
>>*/
>
> This leaves room for a number of suspicious situations. What if both
> "xyz" and "xyz.0" are stm devices, how would you create a policy for the
> latter, for example?
>
> The rules should be such that you can tell exactly what the intended stm
> device is from a policy directory name, otherwise it's just asking for
> trouble.
>
>> - p = strchr(devname, '.');
>> - if (!p) {
>> - kfree(devname);
>> - return ERR_PTR(-EINVAL);
>> - }
>> + for (p = devname; ; p++) {
>> + p = strchr(p, '.');
>> + if (!p) {
>> + kfree(devname);
>> + return ERR_PTR(-EINVAL);
>> + }
>>
>> - *p++ = '\0';
>> + *p = '\0';
>>
>> - stm = stm_find_device(devname);
>> - kfree(devname);
>> + stm = stm_find_device(devname);
>> + if (stm)
>> + break;
>> + *p = '.';
>> + }
>>
>> - if (!stm)
>> - return ERR_PTR(-ENODEV);
>> + kfree(devname);
>
> In the existing code there is a clear distinction between -ENODEV, which
> is to say "we didn't find the device" and -EINVAL, "directory name
> breaks rules/is badly formatted". After the change, it's all -EINVAL,
> which also becomes "we tried everything, sorry".
>
> So, having said all that, does the following patch solve your problem:
Yes, I originally modified as well like your following patch, but at
that moment, I didn't get your agreement that the policy name (i.e. an
arbitrary string) cannot contain dots, so I had to consider the case.
Whatever, there isn't a panacea. I'm very good with your patch. Many
thanks for your review and providing the patch.
Chunyan
>
> From 870dc5fefa5623c39552511d31e0fa0da984d581 Mon Sep 17 00:00:00 2001
> From: Alexander Shishkin
> Date: Thu, 4 Feb 2016 18:56:34 +0200
> Subject: [PATCH] stm class: Support devices with multiple instances
>
> By convention, the name of the stm policy directory in configfs consists of
> the device name to which it applies and the actual policy name, separated
> by a dot. Now, some devices already have dots in their names that separate
> name of the actual device from its instance identifier. Such devices will
> result in two (or more, who can tell) dots in the policy directory name.
>
> Existing policy code, however, will treat the first dot as the one that
> separates device name from policy name, therefore failing the above case.
>
> This patch makes the last dot in the directory name be the separator, thus
> prohibiting dots from being used in policy names.
>
> Suggested-by: Chunyan Zhang
> Signed-off-by: Alexander Shishkin
> ---
> drivers/hwtracing/stm/policy.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hwtracing/stm/policy.c b/drivers/hwtracing/stm/policy.c
> index 94d3abfb73..1db189657b 100644
> --- a/drivers/hwtracing/stm/policy.c
> +++ b/drivers/hwtracing/stm/policy.c
> @@ -332,10 +332,11 @@ stp_policies_make(struct config_group *group, const
> char *name)
>
> /*
> * node must look like ., where
> -* is the name of an existing stm device and
> -* is an arbitrary string
> +* is the name of an existing stm device; may
> +* contain dots;
> +* is an arbitrary string; may not contain dots
> */
> - p = strchr
