Re: [PATCHv3 0/4] drivers/base: bugfix for supplier<-consumer ordering in device_kset
On Sat, Jul 7, 2018 at 6:24 AM, Pingfan Liu wrote: > On Fri, Jul 6, 2018 at 9:55 PM Pingfan Liu wrote: >> >> On Fri, Jul 6, 2018 at 4:47 PM Rafael J. Wysocki wrote: >> > >> > On Fri, Jul 6, 2018 at 10:36 AM, Lukas Wunner wrote: >> > > [cc += Kishon Vijay Abraham] >> > > >> > > On Thu, Jul 05, 2018 at 11:18:28AM +0200, Rafael J. Wysocki wrote: >> > >> OK, so calling devices_kset_move_last() from really_probe() clearly is >> > >> a mistake. >> > >> >> > >> I'm not really sure what the intention of it was as the changelog of >> > >> commit 52cdbdd49853d doesn't really explain that (why would it be >> > >> insufficient without that change?) >> > > >> > > It seems 52cdbdd49853d fixed an issue with boards which have an MMC >> > > whose reset pin needs to be driven high on shutdown, lest the MMC >> > > won't be found on the next boot. >> > > >> > > The boards' devicetrees use a kludge wherein the reset pin is modelled >> > > as a regulator. The regulator is enabled when the MMC probes and >> > > disabled on driver unbind and shutdown. As a result, the pin is driven >> > > low on shutdown and the MMC is not found on the next boot. >> > > >> > > To fix this, another kludge was invented wherein the GPIO expander >> > > driving the reset pin unconditionally drives all its pins high on >> > > shutdown, see pcf857x_shutdown() in drivers/gpio/gpio-pcf857x.c >> > > (commit adc284755055, "gpio: pcf857x: restore the initial line state >> > > of all pcf lines"). >> > > >> > > For this kludge to work, the GPIO expander's ->shutdown hook needs to >> > > be executed after the MMC expander's ->shutdown hook. >> > > >> > > Commit 52cdbdd49853d achieved that by reordering devices_kset according >> > > to the probe order. Apparently the MMC probes after the GPIO expander, >> > > possibly because it returns -EPROBE_DEFER if the vmmc regulator isn't >> > > available yet, see mmc_regulator_get_supply(). >> > > >> > > Note, I'm just piecing the information together from git history, >> > > I'm not responsible for these kludges. (I'm innocent!) >> > >> > Sure enough. :-) >> > >> > In any case, calling devices_kset_move_last() in really_probe() is >> > plain broken and if its only purpose was to address a single, arguably >> > kludgy, use case, let's just get rid of it in the first place IMO. >> > >> Yes, if it is only used for a single use case. >> > Think it again, I saw other potential issue with the current code. > device_link_add->device_reorder_to_tail() can break the > "supplier<-consumer" order. During moving children after parent's > supplier, it ignores the order of child's consumer. What do you mean? > Beside this, essentially both devices_kset_move_after/_before() and > device_pm_move_after/_before() expose the shutdown order to the > indirect caller, and we can not expect that the caller can not handle > it correctly. It should be a job of drivers core. Arguably so, but that's how those functions were designed and the callers should be aware of the limitation. If they aren't, there is a bug in the caller. > It is hard to extract high dimension info and pack them into one dimension > linked-list. Well, yes and no. We know it for a fact that there is a linear ordering that will work. It is inefficient to figure it out every time during system suspend and resume, for one and that's why we have dpm_list. Now, if we have it for suspend and resume, it can also be used for shutdown. > And in theory, it is warranted that the shutdown seq is > correct by using device tree info. More important, it is cheap with > the data structure in hand. So I think it is time to resolve the issue > once for all. Not the way you want to do that, though. Thanks, Rafael
Re: [PATCH 2/3] [v2] m68k: mac: use time64_t in RTC handling
Hi Arnd, Finn,
On Fri, Jun 22, 2018 at 10:55 AM Arnd Bergmann wrote:
> On Fri, Jun 22, 2018 at 7:26 AM, Finn Thain
> wrote:
> > On Tue, 19 Jun 2018, Arnd Bergmann wrote:
> >
> >> The real-time clock on m68k (and powerpc) mac systems uses an unsigned
> >> 32-bit value starting in 1904, which overflows in 2040, about two years
> >> later than everyone else, but this gets wrapped around in the Linux code
> >> in 2038 already because of the deprecated usage of time_t and/or long in
> >> the conversion.
> >>
> >> Getting rid of the deprecated interfaces makes it work until 2040 as
> >> documented, and it could be easily extended by reinterpreting the
> >> resulting time64_t as a positive number. For the moment, I'm adding a
> >> WARN_ON() that triggers if we encounter a time before 1970 or after 2040
> >> (the two are indistinguishable).
> >>
> >
> > I really don't like the WARN_ON(), but I'd prefer to address that in a
> > separate patch rather than impede the progress of this patch (or of this
> > series, since 3/3 seems to be unrelated).
> >
> > BTW, have you considered using the same wrap-around test (i.e. YY < 70)
> > that we use for the year register in the other RTC chips?
>
> That wrap-around test would have the same effect as the my original
> version (aside from the two bugs I now fixed), doing rougly
>
> -return time - RTC_OFFSET;
> +return (u32)(time - RTC_OFFSET);
>
> or some other variation of that will give us an RTC that supports all dates
> between 1970 and 2106. I don't think anyone so far had a strong
> preference here, so I went with what Mathieu suggested and kept the
> original Mac behavior, but added the WARN_ON().
So, is this safe to apply?
Especially in light of the warnings seen by Meelis with the PPC version.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/3] [v2] m68k: mac: use time64_t in RTC handling
On Sun, 8 Jul 2018, Geert Uytterhoeven wrote: > On Fri, Jun 22, 2018 at 10:55 AM Arnd Bergmann wrote: > > I don't think anyone so far had a strong preference here, so I went > > with what Mathieu suggested and kept the original Mac behavior, but > > added the WARN_ON(). > > So, is this safe to apply? > Especially in light of the warnings seen by Meelis with the PPC version. > You mean, "can we apply this and avoid warning splats?" Meelis's result says, "no". I forget what date the RTC gets set to when the PMU/Cuda is reset but I suspect that timezone arithmetic in either MacOS or Linux could cause it to end up in 1969. So I'd prefer to see the WARN_ON() removed. --
Re: powerpc: 32BIT vs. 64BIT (PPC32 vs. PPC64)
Randy Dunlap writes: > Hi, > > Is there a good way (or a shortcut) to do something like: The best I know of is: > $ make ARCH=powerpc O=PPC32 [other_options] allmodconfig > to get a PPC32/32BIT allmodconfig $ echo CONFIG_PPC64=n > allmod.config $ KCONFIG_ALLCONFIG=1 make allmodconfig $ grep PPC32 .config CONFIG_PPC32=y Which is still a bit clunky. I looked at this a while back and the problem we have is that the 32-bit kernel is not a single thing. There are multiple 32-bit platforms which are mutually exclusive. eg, from menuconfig: - 512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx - Freescale 85xx - Freescale 8xx - AMCC 40x - AMCC 44x, 46x or 47x - Freescale e200 So we could have a 32-bit allmodconfig, but we'd need to chose one of the above, and we'd still only be testing some of the code. Having said that you're the 2nd person to ask about this, so we should clearly do something to make a 32-bit allmodconfig easier, even if it's not perfect. cheers
[RFC PATCH] powerpc/64s: Move ISAv3.0 / POWER9 idle code to powernv C code
Reimplement POWER9 idle code in C, in the powernv platform code.
Assembly stubs are used to save and restore the stack frame and
non-volatile GPRs before going to idle, but these are small and
mostly agnostic to microarchitecture implementation details.
POWER7/8 code is not converted (yet), but that's not a moving
target, and it doesn't make you want to claw your eyes out so
much with the POWER9 code untangled from it.
The optimisation where EC=ESL=0 idle modes did not have to save
GPRs or mtmsrd L=0 is restored, because it's simple to do.
Idle wakeup no longer uses the ->cpu_restore call to reinit SPRs,
but saves and restores them all explicitly.
Moving the HMI, SPR, OPAL, locking, etc. to C is the only real
way this stuff will cope with non-trivial new CPU implementation
details, firmware changes, etc., without becoming unmaintainable.
---
arch/powerpc/include/asm/book3s/64/mmu-hash.h | 1 +
arch/powerpc/include/asm/cpuidle.h| 14 +-
arch/powerpc/include/asm/paca.h | 38 +-
arch/powerpc/include/asm/processor.h | 3 +-
arch/powerpc/include/asm/reg.h| 7 +-
arch/powerpc/kernel/Makefile | 2 +-
arch/powerpc/kernel/asm-offsets.c | 11 +-
arch/powerpc/kernel/exceptions-64s.S | 10 +-
arch/powerpc/kernel/idle_book3s.S | 348 ++-
arch/powerpc/kernel/idle_isa3.S | 73
arch/powerpc/kernel/setup-common.c| 4 +-
arch/powerpc/mm/slb.c | 7 +-
arch/powerpc/platforms/powernv/idle.c | 402 +++---
arch/powerpc/xmon/xmon.c | 25 +-
14 files changed, 496 insertions(+), 449 deletions(-)
create mode 100644 arch/powerpc/kernel/idle_isa3.S
diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
index 50ed64fba4ae..c626319a962d 100644
--- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
@@ -486,6 +486,7 @@ static inline void hpte_init_pseries(void) { }
extern void hpte_init_native(void);
extern void slb_initialize(void);
+extern void __slb_flush_and_rebolt(void);
extern void slb_flush_and_rebolt(void);
extern void slb_vmalloc_update(void);
diff --git a/arch/powerpc/include/asm/cpuidle.h
b/arch/powerpc/include/asm/cpuidle.h
index e210a83eb196..b668f030d531 100644
--- a/arch/powerpc/include/asm/cpuidle.h
+++ b/arch/powerpc/include/asm/cpuidle.h
@@ -28,6 +28,7 @@
* yet woken from the winkle state.
*/
#define PNV_CORE_IDLE_LOCK_BIT 0x1000
+#define NR_PNV_CORE_IDLE_LOCK_BIT 28
#define PNV_CORE_IDLE_WINKLE_COUNT 0x0001
#define PNV_CORE_IDLE_WINKLE_COUNT_ALL_BIT 0x0008
@@ -68,22 +69,9 @@
#define ERR_DEEP_STATE_ESL_MISMATCH-2
#ifndef __ASSEMBLY__
-/* Additional SPRs that need to be saved/restored during stop */
-struct stop_sprs {
- u64 pid;
- u64 ldbar;
- u64 fscr;
- u64 hfscr;
- u64 mmcr1;
- u64 mmcr2;
- u64 mmcra;
-};
-
extern u32 pnv_fastsleep_workaround_at_entry[];
extern u32 pnv_fastsleep_workaround_at_exit[];
-extern u64 pnv_first_deep_stop_state;
-
unsigned long pnv_cpu_offline(unsigned int cpu);
int validate_psscr_val_mask(u64 *psscr_val, u64 *psscr_mask, u32 flags);
static inline void report_invalid_psscr_val(u64 psscr_val, int err)
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index 4e9cede5a7e7..a7a4892d39c0 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -178,23 +178,29 @@ struct paca_struct {
#endif
#ifdef CONFIG_PPC_POWERNV
- /* Per-core mask tracking idle threads and a lock bit-[L][] */
- u32 *core_idle_state_ptr;
- u8 thread_idle_state; /* PNV_THREAD_RUNNING/NAP/SLEEP */
- /* Mask to indicate thread id in core */
- u8 thread_mask;
- /* Mask to denote subcore sibling threads */
- u8 subcore_sibling_mask;
- /* Flag to request this thread not to stop */
- atomic_t dont_stop;
- /* The PSSCR value that the kernel requested before going to stop */
- u64 requested_psscr;
+ union {
+ /* P7/P8 specific fields */
+ struct {
+ /* Per-core mask tracking idle threads and a lock
bit-[L][] */
+ unsigned long *core_idle_state_ptr;
+ u8 thread_idle_state; /* PNV_THREAD_RUNNING/NAP/SLEEP
*/
+ /* Mask to indicate thread id in core */
+ u8 thread_mask;
+ /* Mask to denote subcore sibling threads */
+ u8 subcore_sibling_mask;
+ };
- /*
-* Save area for additional SPRs that need to be
-* saved/restored during cpuidle stop.
-*/
- struct stop_sprs stop_sprs;
+ /* P
Re: [RFC PATCH 1/2] dma-mapping: Clean up dma_set_*mask() hooks
On Fri, Jul 06, 2018 at 03:20:34PM +0100, Robin Murphy wrote: >> What are you trying to do? I really don't want to see more users of >> the hooks as they are are a horribly bad idea. > > I really need to fix the ongoing problem we have where, due to funky > integrations, devices suffer some downstream addressing limit (described by > DT dma-ranges or ACPI IORT/_DMA) which we carefully set up in > dma_configure(), but then just gets lost when the driver probes and > innocently calls dma_set_mask() with something wider. I think it's > effectively the generalised case of the VIA 32-bit quirk, if I understand > that one correctly. I'd much rather fix this in generic code. How funky are your limitations? In fact when I did the 32-bit quirk (which will also be used by a Xiling PCIe root port usable on a lot of architectures) I did initially consider adding a bus_dma_mask or similar to struct device, but opted for the most simple implementation for now. I'd be happy to chanfe this. Especially these days where busses and IP blocks are generally not tied to a specific cpu instruction set I really believe that having any more architecture code than absolutely required is a bad idea. > The approach that seemed to me to be safest is largely based on the one > proposed in a thread from ages ago[1]; namely to make dma_configure() > better at distinguishing firmware-specified masks from bus defaults, > capture the firmware mask in dev->archdata during arch_setup_dma_ops(), > then use the custom set_mask routines to ensure any subsequent updates > never exceed that. It doesn't seem possible to make this work robustly > without storing *some* additional per-device data, and for that archdata is > a lesser evil than struct device itself. Plus even though it's not actually > an arch-specific issue it feels like there's such a risk of breaking other > platforms that I'm reticent to even try handling it entirely in generic > code. My plan for a few merge windows from now is that dma_mask and coherent_mask are 100% in device control and dma_set_mask will never fail. It will be up to the dma ops to make sure things are addressible.
Re: powerpc: 32BIT vs. 64BIT (PPC32 vs. PPC64)
On Sat, 7 Jul 2018 07:59:49 -0700 Randy Dunlap wrote: > On 07/07/2018 05:13 AM, Nicholas Piggin wrote: > > On Fri, 6 Jul 2018 21:58:29 -0700 > > Randy Dunlap wrote: > > > >> On 07/06/2018 06:45 PM, Benjamin Herrenschmidt wrote: > >>> On Thu, 2018-07-05 at 14:30 -0700, Randy Dunlap wrote: > Hi, > > Is there a good way (or a shortcut) to do something like: > > $ make ARCH=powerpc O=PPC32 [other_options] allmodconfig > to get a PPC32/32BIT allmodconfig > > and also be able to do: > > $make ARCH=powerpc O=PPC64 [other_options] allmodconfig > to get a PPC64/64BIT allmodconfig? > >>> > >>> Hrm... O= is for the separate build dir, so there much be something > >>> else. > >>> > >>> You mean having ARCH= aliases like ppc/ppc32 and ppc64 ? > >> > >> Yes. > >> > >>> That would be a matter of overriding some .config defaults I suppose, I > >>> don't know how this is done on other archs. > >>> > >>> I see the aliasing trick in the Makefile but that's about it. > >>> > Note that arch/x86, arch/sh, and arch/sparc have ways to do > some flavor(s) of this (from Documentation/kbuild/kbuild.txt; > sh and sparc based on a recent "fix" patch from me): > >>> > >>> I fail to see what you are actually talking about here ... sorry. Do > >>> you have concrete examples on x86 or sparc ? From what I can tell the > >>> "i386" or "sparc32/sparc64" aliases just change SRCARCH in Makefile and > >>> 32 vs 64-bit is just a Kconfig option... > >> > >> Yes, your summary is mostly correct. > >> > >> I'm just looking for a way to do cross-compile builds that are close to > >> ppc32 allmodconfig and ppc64 allmodconfig. > > > > Would there a problem with adding ARCH=ppc32 / ppc64 matching? This > > seems to work... > > > > Thanks, > > Nick > > Yes, this mostly works and is similar to a patch (my patch) on my test > machine. > And they both work for allmodconfig, which is my primary build target. > > And they both have one little quirk that is confusing when the build target > is defconfig: > > When ARCH=ppc32, the terminal output (stdout) is: (using O=PPC32) > > make[1]: Entering directory '/home/rdunlap/lnx/lnx-418-rc3/PPC32' > GEN ./Makefile > *** Default configuration is based on 'ppc64_defconfig' < NOTE < > # > # configuration written to .config > # > make[1]: Leaving directory '/home/rdunlap/lnx/lnx-418-rc3/PPC32' > > > I expect that can be fixed also. :) It can, we'd just have to choose one of the many 32-bit configs to be the default config in that case. I don't know much about 32 bit ppc, so I don't know what would be the most useful for allmodconfig type of build tests. Even 64 bit have a bunch of major variants that are exclusive at build time (Server vs embedded, endian, etc). So maybe the simple ppc64/ppc32 is not enough. Not sure. Thanks, Nick
Re: powerpc: 32BIT vs. 64BIT (PPC32 vs. PPC64)
On 07/08/2018 04:51 AM, Michael Ellerman wrote: > Randy Dunlap writes: >> Hi, >> >> Is there a good way (or a shortcut) to do something like: > > The best I know of is: > >> $ make ARCH=powerpc O=PPC32 [other_options] allmodconfig >> to get a PPC32/32BIT allmodconfig > > $ echo CONFIG_PPC64=n > allmod.config > $ KCONFIG_ALLCONFIG=1 make allmodconfig > $ grep PPC32 .config > CONFIG_PPC32=y > > Which is still a bit clunky. > That's close to what I already do. And it's very script-able. > > I looked at this a while back and the problem we have is that the 32-bit > kernel is not a single thing. There are multiple 32-bit platforms which > are mutually exclusive. > > eg, from menuconfig: > > - 512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx > - Freescale 85xx > - Freescale 8xx > - AMCC 40x > - AMCC 44x, 46x or 47x > - Freescale e200 > > > So we could have a 32-bit allmodconfig, but we'd need to chose one of > the above, and we'd still only be testing some of the code. > > Having said that you're the 2nd person to ask about this, so we should > clearly do something to make a 32-bit allmodconfig easier, even if it's > not perfect. Thanks. -- ~Randy
Re: [PATCH v3 1/2] powerpc: Detect the presence of big-cores via "ibm, thread-groups"
On Fri, Jul 06, 2018 at 02:35:48PM +0530, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy"
>
> On IBM POWER9, the device tree exposes a property array identifed by
> "ibm,thread-groups" which will indicate which groups of threads share a
> particular set of resources.
>
> As of today we only have one form of grouping identifying the group of
> threads in the core that share the L1 cache, translation cache and
> instruction data flow.
>
> This patch defines the helper function to parse the contents of
> "ibm,thread-groups" and a new structure to contain the parsed output.
>
> The patch also creates the sysfs file named "small_core_siblings" that
> returns the physical ids of the threads in the core that share the L1
> cache, translation cache and instruction data flow.
>
> Signed-off-by: Gautham R. Shenoy
> ---
> Documentation/ABI/testing/sysfs-devices-system-cpu | 8 ++
> arch/powerpc/include/asm/cputhreads.h | 22 +++
> arch/powerpc/kernel/setup-common.c | 154
> +
> arch/powerpc/kernel/sysfs.c| 35 +
> 4 files changed, 219 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu
> b/Documentation/ABI/testing/sysfs-devices-system-cpu
> index 9c5e7732..62f24de 100644
> --- a/Documentation/ABI/testing/sysfs-devices-system-cpu
> +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
> @@ -487,3 +487,11 @@ Description: Information about CPU vulnerabilities
> "Not affected"CPU is not affected by the vulnerability
> "Vulnerable" CPU is affected and no mitigation in effect
> "Mitigation: $M" CPU is affected and mitigation $M is in effect
> +
> +What:/sys/devices/system/cpu/cpu[0-9]+/small_core_siblings
> +Date:05-Jul-2018
> +KernelVersion: v4.18.0
> +Contact: Gautham R. Shenoy
> +Description: List of Physical ids of CPUs which share the the L1 cache,
> + translation cache and instruction data-flow with this CPU.
What about this?
Description: List of physical CPU IDs that share a common L1 cache,
translation cache and instruction data flow with this CPU.
Or perhaps just remove the extra "the".
> +Values: Comma separated list of decimal integers.
> diff --git a/arch/powerpc/include/asm/cputhreads.h
> b/arch/powerpc/include/asm/cputhreads.h
> index d71a909..33226d7 100644
> --- a/arch/powerpc/include/asm/cputhreads.h
> +++ b/arch/powerpc/include/asm/cputhreads.h
> @@ -23,11 +23,13 @@
> extern int threads_per_core;
> extern int threads_per_subcore;
> extern int threads_shift;
> +extern bool has_big_cores;
> extern cpumask_t threads_core_mask;
> #else
> #define threads_per_core 1
> #define threads_per_subcore 1
> #define threads_shift0
> +#define has_big_cores0
> #define threads_core_mask(*get_cpu_mask(0))
> #endif
>
> @@ -69,12 +71,32 @@ static inline cpumask_t cpu_online_cores_map(void)
> return cpu_thread_mask_to_cores(cpu_online_mask);
> }
>
> +#define MAX_THREAD_LIST_SIZE 8
> +struct thread_groups {
> + unsigned int property;
> + unsigned int nr_groups;
> + unsigned int threads_per_group;
> + unsigned int thread_list[MAX_THREAD_LIST_SIZE];
> +};
> +
> #ifdef CONFIG_SMP
> int cpu_core_index_of_thread(int cpu);
> int cpu_first_thread_of_core(int core);
> +int parse_thread_groups(struct device_node *dn, struct thread_groups *tg);
> +int get_cpu_thread_group_start(int cpu, struct thread_groups *tg);
> #else
> static inline int cpu_core_index_of_thread(int cpu) { return cpu; }
> static inline int cpu_first_thread_of_core(int core) { return core; }
> +static inline int parse_thread_groups(struct device_node *dn,
> + struct thread_groups *tg)
> +{
> + return -ENODATA;
> +}
> +
> +static inline int get_cpu_thread_group_start(int cpu, struct thread_groups
> *tg)
> +{
> + return -1;
> +}
> #endif
>
> static inline int cpu_thread_in_core(int cpu)
> diff --git a/arch/powerpc/kernel/setup-common.c
> b/arch/powerpc/kernel/setup-common.c
> index 40b44bb..989edc1 100644
> --- a/arch/powerpc/kernel/setup-common.c
> +++ b/arch/powerpc/kernel/setup-common.c
> @@ -402,10 +402,12 @@ void __init check_for_initrd(void)
> #ifdef CONFIG_SMP
>
> int threads_per_core, threads_per_subcore, threads_shift;
> +bool has_big_cores;
> cpumask_t threads_core_mask;
> EXPORT_SYMBOL_GPL(threads_per_core);
> EXPORT_SYMBOL_GPL(threads_per_subcore);
> EXPORT_SYMBOL_GPL(threads_shift);
> +EXPORT_SYMBOL_GPL(has_big_cores);
> EXPORT_SYMBOL_GPL(threads_core_mask);
>
> static void __init cpu_init_thread_core_maps(int tpc)
> @@ -433,6 +435,152 @@ static void __init cpu_init_thread_core_maps(int tpc)
>
> u32 *cpu_to_phys_id = NULL;
>
> +/*
> + * parse_thread_groups: Parses the "ibm,thread-groups" device tree
> + * property f
Re: [PATCH v6 2/4] resource: Use list_head to link sibling resource
On Sun, Jul 8, 2018 at 5:59 AM, Baoquan He wrote:
> On 07/05/18 at 01:00am, kbuild test robot wrote:
> However, I didn't find below branch. And tried to open it in web
> broswer, also failed.
While this is kinda valid point...
> Could you help have a look at this?
...isn't obvious that you didn't change the file mentioned in a report?
Just take latest linux-next and you will see.
>> All error/warnings (new ones prefixed by >>):
>>
>> >> arch/mips/pci/pci-rc32434.c:57:11: error: initialization from
>> >> incompatible pointer type [-Werror=incompatible-pointer-types]
>> .child = &rc32434_res_pci_mem2
>> ^
>>arch/mips/pci/pci-rc32434.c:57:11: note: (near initialization for
>> 'rc32434_res_pci_mem1.child.next')
>> >> arch/mips/pci/pci-rc32434.c:51:47: warning: missing braces around
>> >> initializer [-Wmissing-braces]
>> static struct resource rc32434_res_pci_mem1 = {
>> ^
>>arch/mips/pci/pci-rc32434.c:60:47: warning: missing braces around
>> initializer [-Wmissing-braces]
>> static struct resource rc32434_res_pci_mem2 = {
>> ^
>>cc1: some warnings being treated as errors
>>
>> vim +57 arch/mips/pci/pci-rc32434.c
>>
>> 73b4390f Ralf Baechle 2008-07-16 50
>> 73b4390f Ralf Baechle 2008-07-16 @51 static struct resource
>> rc32434_res_pci_mem1 = {
>> 73b4390f Ralf Baechle 2008-07-16 52 .name = "PCI MEM1",
>> 73b4390f Ralf Baechle 2008-07-16 53 .start = 0x5000,
>> 73b4390f Ralf Baechle 2008-07-16 54 .end = 0x5FFF,
>> 73b4390f Ralf Baechle 2008-07-16 55 .flags = IORESOURCE_MEM,
>> 73b4390f Ralf Baechle 2008-07-16 56 .sibling = NULL,
>> 73b4390f Ralf Baechle 2008-07-16 @57 .child = &rc32434_res_pci_mem2
>> 73b4390f Ralf Baechle 2008-07-16 58 };
>> 73b4390f Ralf Baechle 2008-07-16 59
>>
>> :: The code at line 57 was first introduced by commit
>> :: 73b4390fb23456964201abda79f1210fe337d01a [MIPS] Routerboard 532:
>> Support for base system
>>
>> :: TO: Ralf Baechle
>> :: CC: Ralf Baechle
>>
>> ---
>> 0-DAY kernel test infrastructureOpen Source Technology Center
>> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCHv6 0/4] Salted build ids via ELF notes
2018-07-06 9:49 GMT+09:00 Laura Abbott : > Hi, > > This is v6 of the series to allow unique build ids. v6 is mostly minor > fixups and Acks for this to go through the kbuild tree. Applied to linux-kbuild. Thanks! > Thanks, > Laura > > Laura Abbott (4): > kbuild: Add build salt to the kernel and modules > x86: Add build salt to the vDSO > powerpc: Add build salt to the vDSO > arm64: Add build salt to the vDSO > > arch/arm64/kernel/vdso/note.S | 3 +++ > arch/powerpc/kernel/vdso32/note.S | 3 +++ > arch/x86/entry/vdso/vdso-note.S | 3 +++ > arch/x86/entry/vdso/vdso32/note.S | 3 +++ > include/linux/build-salt.h| 20 > init/Kconfig | 9 + > init/version.c| 3 +++ > scripts/mod/modpost.c | 3 +++ > 8 files changed, 47 insertions(+) > create mode 100644 include/linux/build-salt.h > > -- > 2.17.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best Regards Masahiro Yamada
Re: [PATCH v4 3/3] hwmon: Document the sensor enable attribute
On 07/06/2018 04:56 AM, Shilpasri G Bhat wrote: Signed-off-by: Shilpasri G Bhat Applied to hwmon-next, after updating the commit description. I also removed the text "This attribute can be used as per-sensor or per-sub-group attribute depending on what is supported by the hardware." from the attribute descriptions; this is an implementation detail which should be described in driver documentations. Thanks, Guenter --- Documentation/hwmon/sysfs-interface | 62 + 1 file changed, 62 insertions(+) diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index fc337c3..f865dd7 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -171,6 +171,15 @@ in[0-*]_label Suggested voltage channel label. user-space. RO +in[0-*]_enable + Enable or disable the sensors. + When disabled the sensor read will return -ENODATA. This + attribute can be used as per-sensor or per-sub-group attribute + depending on what is supported by the hardware. + 1: Enable + 0: Disable + RW + cpu[0-*]_vid CPU core reference voltage. Unit: millivolt RO @@ -236,6 +245,15 @@ fan[1-*]_label Suggested fan channel label. In all other cases, the label is provided by user-space. RO +fan[1-*]_enable + Enable or disable the sensors. + When disabled the sensor read will return -ENODATA. This + attribute can be used as per-sensor or per-sub-group attribute + depending on what is supported by the hardware. + 1: Enable + 0: Disable + RW + Also see the Alarms section for status flags associated with fans. @@ -409,6 +427,15 @@ temp_reset_history Reset temp_lowest and temp_highest for all sensors WO +temp[1-*]_enable + Enable or disable the sensors. + When disabled the sensor read will return -ENODATA. This + attribute can be used as per-sensor or per-sub-group attribute + depending on what is supported by the hardware. + 1: Enable + 0: Disable + RW + Some chips measure temperature using external thermistors and an ADC, and report the temperature measurement as a voltage. Converting this voltage back to a temperature (or the other way around for limits) requires @@ -468,6 +495,15 @@ curr_reset_history Reset currX_lowest and currX_highest for all sensors WO +curr[1-*]_enable + Enable or disable the sensors. + When disabled the sensor read will return -ENODATA. This + attribute can be used as per-sensor or per-sub-group attribute + depending on what is supported by the hardware. + 1: Enable + 0: Disable + RW + Also see the Alarms section for status flags associated with currents. * @@ -566,6 +602,15 @@ power[1-*]_critCritical maximum power. Unit: microWatt RW +power[1-*]_enable Enable or disable the sensors. + When disabled the sensor read will return + -ENODATA. This attribute can be used as + per-sensor or per-sub-group attribute depending + on what is supported by the hardware. + 1: Enable + 0: Disable + RW + Also see the Alarms section for status flags associated with power readings. ** @@ -576,6 +621,14 @@ energy[1-*]_input Cumulative energy use Unit: microJoule RO +energy[1-*]_enable Enable or disable the sensors. + When disabled the sensor read will return + -ENODATA. This attribute can be used as + per-sensor or per-sub-group attribute depending + on what is supported by the hardware. + 1: Enable + 0: Disable + RW * Humidity * @@ -586,6 +639,15 @@ humidity[1-*]_inputHumidity RO +humidity[1-*]_enable Enable or disable the sensors + When disabled the sensor read will return + -ENODATA. This attribute can be used as + per-sensor or per-sub-group attribute depending +
Re: [PATCH v4 2/3] hwmon: ibmpowernv: Add attributes to enable/disable sensor groups
On 07/06/2018 04:56 AM, Shilpasri G Bhat wrote:
On-Chip-Controller(OCC) is an embedded micro-processor in POWER9 chip
which measures various system and chip level sensors. These sensors
comprises of environmental sensors (like power, temperature, current
and voltage) and performance sensors (like utilization, frequency).
All these sensors are copied to main memory at a regular interval of
100ms. OCC provides a way to select a group of sensors that is copied
to the main memory to increase the update frequency of selected sensor
groups. When a sensor-group is disabled, OCC will not copy it to main
memory and those sensors read 0 values.
This patch provides support for enabling/disabling the sensor groups
like power, temperature, current and voltage. This patch adds new
per-senor sysfs attribute to disable and enable them.
Signed-off-by: Shilpasri G Bhat
I assume this will be merged through some powerpc tree since it depends
on patch 1/3. With that in mind,
Acked-by: Guenter Roeck
---
Changes from v3:
- Add 'enable' attribute for each sensor sub-group
Documentation/hwmon/ibmpowernv | 43 +++-
drivers/hwmon/ibmpowernv.c | 225 +++--
2 files changed, 234 insertions(+), 34 deletions(-)
diff --git a/Documentation/hwmon/ibmpowernv b/Documentation/hwmon/ibmpowernv
index 8826ba2..5646825 100644
--- a/Documentation/hwmon/ibmpowernv
+++ b/Documentation/hwmon/ibmpowernv
@@ -33,9 +33,48 @@ fanX_input Measured RPM value.
fanX_min Threshold RPM for alert generation.
fanX_fault0: No fail condition
1: Failing fan
+
tempX_input Measured ambient temperature.
tempX_max Threshold ambient temperature for alert generation.
-inX_input Measured power supply voltage
+tempX_highest Historical maximum temperature
+tempX_lowest Historical minimum temperature
[ You are sneaking those in. Just letting you know that I noticed. ]
+tempX_enable Enable/disable all temperature sensors belonging to the
+ sub-group. In POWER9, this attribute corresponds to
+ each OCC. Using this attribute each OCC can be asked to
+ disable/enable all of its temperature sensors.
+ 1: Enable
+ 0: Disable
+
+inX_input Measured power supply voltage (millivolt)
inX_fault 0: No fail condition.
1: Failing power supply.
-power1_input System power consumption (microWatt)
+inX_highestHistorical maximum voltage
+inX_lowest Historical minimum voltage
+inX_enable Enable/disable all voltage sensors belonging to the
+ sub-group. In POWER9, this attribute corresponds to
+ each OCC. Using this attribute each OCC can be asked to
+ disable/enable all of its voltage sensors.
+ 1: Enable
+ 0: Disable
+
+powerX_input Power consumption (microWatt)
+powerX_input_highest Historical maximum power
+powerX_input_lowestHistorical minimum power
+powerX_enable Enable/disable all power sensors belonging to the
+ sub-group. In POWER9, this attribute corresponds to
+ each OCC. Using this attribute each OCC can be asked to
+ disable/enable all of its power sensors.
+ 1: Enable
+ 0: Disable
+
+currX_inputMeasured current (milliampere)
+currX_highest Historical maximum current
+currX_lowest Historical minimum current
+currX_enable Enable/disable all current sensors belonging to the
+ sub-group. In POWER9, this attribute corresponds to
+ each OCC. Using this attribute each OCC can be asked to
+ disable/enable all of its current sensors.
+ 1: Enable
+ 0: Disable
+
+energyX_input Cumulative energy (microJoule)
diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index f829dad..33cf7d2 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -90,11 +90,23 @@ struct sensor_data {
char label[MAX_LABEL_LEN];
char name[MAX_ATTR_LEN];
struct device_attribute dev_attr;
+ struct sensor_group_data *sgdata;
+};
+
+struct sensor_group_data {
+ struct mutex mutex;
+ const __be32 *phandles;
+ u32 gid;
+ u32 nr_phandle;
+ enum sensors type;
+ bool enable;
};
struct platform_data {
const struct attribute_group *attr_groups[MAX_SENSOR_TYPE + 1];
+ struct sensor_group_data *sg_data;
u32 sensors_count; /* Total count of sensors from each group */
+ u32 nr_sensor_groups; /* Total number of s
Re: [PATCH v6 2/4] resource: Use list_head to link sibling resource
On 07/08/18 at 08:48pm, Andy Shevchenko wrote:
> On Sun, Jul 8, 2018 at 5:59 AM, Baoquan He wrote:
> > On 07/05/18 at 01:00am, kbuild test robot wrote:
>
> > However, I didn't find below branch. And tried to open it in web
> > broswer, also failed.
>
> While this is kinda valid point...
>
> > Could you help have a look at this?
>
> ...isn't obvious that you didn't change the file mentioned in a report?
> Just take latest linux-next and you will see.
Yes, it's clear to me. Just want to use the way to cross compile them on
ia64 and mips, hope I can find out all missed places on these ARCHes.
Now I think I can apply patches on linux-next, and use the config
attached to compile. Thanks.
>
>
> >> All error/warnings (new ones prefixed by >>):
> >>
> >> >> arch/mips/pci/pci-rc32434.c:57:11: error: initialization from
> >> >> incompatible pointer type [-Werror=incompatible-pointer-types]
> >> .child = &rc32434_res_pci_mem2
> >> ^
> >>arch/mips/pci/pci-rc32434.c:57:11: note: (near initialization for
> >> 'rc32434_res_pci_mem1.child.next')
> >> >> arch/mips/pci/pci-rc32434.c:51:47: warning: missing braces around
> >> >> initializer [-Wmissing-braces]
> >> static struct resource rc32434_res_pci_mem1 = {
> >> ^
> >>arch/mips/pci/pci-rc32434.c:60:47: warning: missing braces around
> >> initializer [-Wmissing-braces]
> >> static struct resource rc32434_res_pci_mem2 = {
> >> ^
> >>cc1: some warnings being treated as errors
> >>
> >> vim +57 arch/mips/pci/pci-rc32434.c
> >>
> >> 73b4390f Ralf Baechle 2008-07-16 50
> >> 73b4390f Ralf Baechle 2008-07-16 @51 static struct resource
> >> rc32434_res_pci_mem1 = {
> >> 73b4390f Ralf Baechle 2008-07-16 52 .name = "PCI MEM1",
> >> 73b4390f Ralf Baechle 2008-07-16 53 .start = 0x5000,
> >> 73b4390f Ralf Baechle 2008-07-16 54 .end = 0x5FFF,
> >> 73b4390f Ralf Baechle 2008-07-16 55 .flags = IORESOURCE_MEM,
> >> 73b4390f Ralf Baechle 2008-07-16 56 .sibling = NULL,
> >> 73b4390f Ralf Baechle 2008-07-16 @57 .child =
> >> &rc32434_res_pci_mem2
> >> 73b4390f Ralf Baechle 2008-07-16 58 };
> >> 73b4390f Ralf Baechle 2008-07-16 59
> >>
> >> :: The code at line 57 was first introduced by commit
> >> :: 73b4390fb23456964201abda79f1210fe337d01a [MIPS] Routerboard 532:
> >> Support for base system
> >>
> >> :: TO: Ralf Baechle
> >> :: CC: Ralf Baechle
> >>
> >> ---
> >> 0-DAY kernel test infrastructureOpen Source Technology
> >> Center
> >> https://lists.01.org/pipermail/kbuild-all Intel
> >> Corporation
> >
> >
>
>
>
> --
> With Best Regards,
> Andy Shevchenko
Re: [PATCH v3 1/2] powerpc: Detect the presence of big-cores via "ibm, thread-groups"
On Sun, 2018-07-08 at 13:03 -0300, Murilo Opsfelder Araujo wrote:
> On Fri, Jul 06, 2018 at 02:35:48PM +0530, Gautham R. Shenoy wrote:
> > From: "Gautham R. Shenoy"
> >
> > On IBM POWER9, the device tree exposes a property array identifed by
> > "ibm,thread-groups" which will indicate which groups of threads share a
> > particular set of resources.
[]
> > diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
[]
> > @@ -1025,6 +1026,33 @@ static ssize_t show_physical_id(struct device *dev,
> > }
> > static DEVICE_ATTR(physical_id, 0444, show_physical_id, NULL);
> >
> > +static ssize_t show_small_core_siblings(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf)
> > +{
>
> Interesting enough, checkpatch.pl warned about this function name:
>
> WARNING: Consider renaming function(s) 'show_small_core_siblings' to
> 'small_core_siblings_show'
> #354: FILE: arch/powerpc/kernel/sysfs.c:1053:
> +}
It's to allow the DEVICE_ATTR below to be renamed to DEVICE_ATTR_RO
> > +static DEVICE_ATTR(small_core_siblings, 0444, show_small_core_siblings,
> > NULL);
So this becomes
DEVICE_ATTR_RO(small_core_siblings)
[PATCH] powerpc64s: Show ori31 availability in spectre_v1 sysfs file not v2
When I added the spectre_v2 information in sysfs, I included the
availability of the ori31 speculation barrier.
Although the ori31 barrier can be used to mitigate v2, it's primarily
intended as a spectre v1 mitigation. Spectre v2 is mitigated by
hardware changes.
So rework the sysfs files to show the ori31 information in the
spectre_v1 file, rather than v2.
Currently we display eg:
$ grep . spectre_v*
spectre_v1:Mitigation: __user pointer sanitization
spectre_v2:Mitigation: Indirect branch cache disabled, ori31 speculation
barrier enabled
After:
$ grep . spectre_v*
spectre_v1:Mitigation: __user pointer sanitization, ori31 speculation barrier
enabled
spectre_v2:Mitigation: Indirect branch cache disabled
Fixes: d6fbe1c55c55 ("powerpc/64s: Wire up cpu_show_spectre_v2()")
Cc: sta...@vger.kernel.org # v4.17+
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/security.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index a8b277362931..4cb8f1f7b593 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -117,25 +117,35 @@ ssize_t cpu_show_meltdown(struct device *dev, struct
device_attribute *attr, cha
ssize_t cpu_show_spectre_v1(struct device *dev, struct device_attribute *attr,
char *buf)
{
- if (!security_ftr_enabled(SEC_FTR_BNDS_CHK_SPEC_BAR))
- return sprintf(buf, "Not affected\n");
+ struct seq_buf s;
+
+ seq_buf_init(&s, buf, PAGE_SIZE - 1);
- if (barrier_nospec_enabled)
- return sprintf(buf, "Mitigation: __user pointer
sanitization\n");
+ if (security_ftr_enabled(SEC_FTR_BNDS_CHK_SPEC_BAR)) {
+ if (barrier_nospec_enabled)
+ seq_buf_printf(&s, "Mitigation: __user pointer
sanitization");
+ else
+ seq_buf_printf(&s, "Vulnerable");
- return sprintf(buf, "Vulnerable\n");
+ if (security_ftr_enabled(SEC_FTR_SPEC_BAR_ORI31))
+ seq_buf_printf(&s, ", ori31 speculation barrier
enabled");
+
+ seq_buf_printf(&s, "\n");
+ } else
+ seq_buf_printf(&s, "Not affected\n");
+
+ return s.len;
}
ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *attr,
char *buf)
{
- bool bcs, ccd, ori;
struct seq_buf s;
+ bool bcs, ccd;
seq_buf_init(&s, buf, PAGE_SIZE - 1);
bcs = security_ftr_enabled(SEC_FTR_BCCTRL_SERIALISED);
ccd = security_ftr_enabled(SEC_FTR_COUNT_CACHE_DISABLED);
- ori = security_ftr_enabled(SEC_FTR_SPEC_BAR_ORI31);
if (bcs || ccd) {
seq_buf_printf(&s, "Mitigation: ");
@@ -151,9 +161,6 @@ ssize_t cpu_show_spectre_v2(struct device *dev, struct
device_attribute *attr, c
} else
seq_buf_printf(&s, "Vulnerable");
- if (ori)
- seq_buf_printf(&s, ", ori31 speculation barrier enabled");
-
seq_buf_printf(&s, "\n");
return s.len;
--
2.14.1
Re: [PATCHv3 0/4] drivers/base: bugfix for supplier<-consumer ordering in device_kset
On Sun, Jul 8, 2018 at 4:25 PM Rafael J. Wysocki wrote: > > On Sat, Jul 7, 2018 at 6:24 AM, Pingfan Liu wrote: > > On Fri, Jul 6, 2018 at 9:55 PM Pingfan Liu wrote: > >> > >> On Fri, Jul 6, 2018 at 4:47 PM Rafael J. Wysocki wrote: > >> > > >> > On Fri, Jul 6, 2018 at 10:36 AM, Lukas Wunner wrote: > >> > > [cc += Kishon Vijay Abraham] > >> > > > >> > > On Thu, Jul 05, 2018 at 11:18:28AM +0200, Rafael J. Wysocki wrote: > >> > >> OK, so calling devices_kset_move_last() from really_probe() clearly is > >> > >> a mistake. > >> > >> > >> > >> I'm not really sure what the intention of it was as the changelog of > >> > >> commit 52cdbdd49853d doesn't really explain that (why would it be > >> > >> insufficient without that change?) > >> > > > >> > > It seems 52cdbdd49853d fixed an issue with boards which have an MMC > >> > > whose reset pin needs to be driven high on shutdown, lest the MMC > >> > > won't be found on the next boot. > >> > > > >> > > The boards' devicetrees use a kludge wherein the reset pin is modelled > >> > > as a regulator. The regulator is enabled when the MMC probes and > >> > > disabled on driver unbind and shutdown. As a result, the pin is driven > >> > > low on shutdown and the MMC is not found on the next boot. > >> > > > >> > > To fix this, another kludge was invented wherein the GPIO expander > >> > > driving the reset pin unconditionally drives all its pins high on > >> > > shutdown, see pcf857x_shutdown() in drivers/gpio/gpio-pcf857x.c > >> > > (commit adc284755055, "gpio: pcf857x: restore the initial line state > >> > > of all pcf lines"). > >> > > > >> > > For this kludge to work, the GPIO expander's ->shutdown hook needs to > >> > > be executed after the MMC expander's ->shutdown hook. > >> > > > >> > > Commit 52cdbdd49853d achieved that by reordering devices_kset according > >> > > to the probe order. Apparently the MMC probes after the GPIO expander, > >> > > possibly because it returns -EPROBE_DEFER if the vmmc regulator isn't > >> > > available yet, see mmc_regulator_get_supply(). > >> > > > >> > > Note, I'm just piecing the information together from git history, > >> > > I'm not responsible for these kludges. (I'm innocent!) > >> > > >> > Sure enough. :-) > >> > > >> > In any case, calling devices_kset_move_last() in really_probe() is > >> > plain broken and if its only purpose was to address a single, arguably > >> > kludgy, use case, let's just get rid of it in the first place IMO. > >> > > >> Yes, if it is only used for a single use case. > >> > > Think it again, I saw other potential issue with the current code. > > device_link_add->device_reorder_to_tail() can break the > > "supplier<-consumer" order. During moving children after parent's > > supplier, it ignores the order of child's consumer. > > What do you mean? > The drivers use device_link_add() to build "supplier<-consumer" order without knowing each other. Hence there is the following potential odds: (consumerX, child_a, ...) (consumer_a,..) (supplierX), where consumer_a consumes child_a. When device_link_add()->device_reorder_to_tail() moves all descendant of consumerX to the tail, it breaks the "supplier<-consumer" order by "consumer_a <- child_a". And we need recrusion to resolve the item in (consumer_a,..), each time when moving a consumer behind its supplier, we may break "parent<-child". > > Beside this, essentially both devices_kset_move_after/_before() and > > device_pm_move_after/_before() expose the shutdown order to the > > indirect caller, and we can not expect that the caller can not handle > > it correctly. It should be a job of drivers core. > > Arguably so, but that's how those functions were designed and the > callers should be aware of the limitation. > > If they aren't, there is a bug in the caller. > If we consider device_move()-> device_pm_move_after/_before() more carefully like the above description, then we can hide the detail from caller. And keep the info of the pm order inside the core. > > It is hard to extract high dimension info and pack them into one dimension > > linked-list. > > Well, yes and no. > For "hard", I means that we need two interleaved recursion to make the order correct. Otherwise, I think it is a bug or limitation. > We know it for a fact that there is a linear ordering that will work. > It is inefficient to figure it out every time during system suspend > and resume, for one and that's why we have dpm_list. > Yeah, I agree that iterating over device tree may hurt performance. I guess the iterating will not cost the majority of the suspend time, comparing to the device_suspend(), which causes hardware's sync. But data is more persuasive. Besides the performance, do you have other concern till now? > Now, if we have it for suspend and resume, it can also be used for shutdown. > Yes, I do think so. Thanks and regards, Pingfan
