Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume
On Mon, Oct 16, 2017 at 03:12:35AM +0200, Rafael J. Wysocki wrote: > Hi All, > > Well, this took more time than expected, as I tried to cover everything I had > in mind regarding PM flags for drivers. > > This work was triggered by attempts to fix and optimize PM in the > i2c-designware-platdev driver that ended up with adding a couple of > flags to the driver's internal data structures for the tracking of > device state (https://marc.info/?l=linux-acpi&m=150629646805636&w=2). > That approach is sort of suboptimal, though, because other drivers will > probably want to do similar things and if all of them need to use internal > flags for that, quite a bit of code duplication may ensue at least. > > That can be avoided in a couple of ways and one of them is to provide a means > for drivers to tell the core what to do and to make the core take care of it > if told to do so. Hence, the idea to use driver flags for system-wide PM > that was briefly discussed during the LPC in LA last month. > > One of the flags considered at that time was to possibly cause the core > to reuse the runtime PM callback path of a device for system suspend/resume. > Admittedly, that idea didn't look too bad to me until I had started to try to > implement it and I got to the PCI bus type's hibernation callbacks. Then, I > moved the patch I was working on to /dev/null right away. I mean it. > > No, this is not going to happen. No way. > > Moreover, that experience made me realize that the whole *idea* of using the > runtime PM callback path for system-wide PM was actually totally bogus (sorry > Ulf). > > The whole point of having different callbacks pointers for different types of > device transitions is because it may be necessary to do different things in > those callbacks in general. Now, if you consider runtime PM and system > suspend/resume *only* and from a driver perspective, then yes, in some cases > the same pair of callback routines may be used for all suspend-like and > resume-like transitions of the device, but if you add hibernation to the mix, > then it is not so clear any more unless the callbacks don't actually do any > power management at all, but simply quiesce the device's activity and then > activate it again. Namely, changing power states of devices during the > hibernation's "freeze" and "thaw" transitions rarely makes sense at all and > the "restore" transition needs to be able to cope with uninitialized devices > (in fact, it should be prepared to cope with devices in *any* state), so > runtime PM is hardly suitable for them. Still, if a *driver* choses to not > do any real PM in its PM callbacks and leaves that to a middle layer (quite > a few drivers do that), then it possibly can use one pair of callbacks in all > cases and be happy, but middle layers pretty much have to use different > callback routines for different transitions. > > If you are a middle layer, your role is basically to do PM for a certain > group of devices. Thus you cannot really do the same in ->suspend or > ->suspend_early and in ->runtime_suspend (because the former generally need to > take device_may_wakeup() into account and the latter doesn't) and you > shouldn't > really do the same in ->suspend and ->freeze (becuase the latter shouldn't > change the device's power state) and so on. To put it bluntly, trying > to use the ->runtime_suspend callback of a middle layer for anything other > than runtime suspend is complete and utter nonsense. At the same time, the > ->runtime_resume callback of a middle layer may be reused to some extent, > but even that doesn't cover the "thaw" transitions during hibernation. > > What can work (and this is the only strategy that can work AFAICS) is to > point different callback pointers *in* *a* *driver* to the same routine > if the driver wants to reuse that code. That actually will work for PCI > and USB drivers today, at least most of the time, but unfortunately there > are problems with it for, say, platform devices. > > The first problem is the requirement to track the status of the device > (suspended vs not suspended) in the callbacks, because the system-wide PM > code in the PM core doesn't do that. The runtime PM framework does it, so > this means adding some extra code which isn't necessary for runtime PM to > the callback routines and that is not particularly nice. > > The second problem is that, if the driver wants to do anything in its > ->suspend callback, it generally has to prevent runtime suspend of the > device from taking place in parallel with that, which is quite cumbersome. > Usually, that is taken care of by resuming the device from runtime suspend > upfront, but generally doing that is wasteful (there may be no real need to > resume the device except for the fact that the code is designed this way). > > On top of the above, there are optimizations to be made, like leaving certain > devices in suspend after system resume to avoid wasting time on waiting fo
Re: [PATCH] PM / core: Fix kerneldoc comments of four functions
On 13 October 2017 at 15:25, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Fix the kerneldoc comments of __device_suspend_noirq(), > __device_suspend_late() and __device_suspend() where the function > names in kerneldoc don't match the actual names of the functions. > > Also fix the device_resume_noirq() kerneldoc comment which mentions > "early resume" instead of "noirq resume" incorrectly. > > Signed-off-by: Rafael J. Wysocki Reviewed-by: Ulf Hansson > --- > drivers/base/power/main.c |8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > Index: linux-pm/drivers/base/power/main.c > === > --- linux-pm.orig/drivers/base/power/main.c > +++ linux-pm/drivers/base/power/main.c > @@ -528,7 +528,7 @@ static void dpm_watchdog_clear(struct dp > /*- Resume routines -*/ > > /** > - * device_resume_noirq - Execute an "early resume" callback for given device. > + * device_resume_noirq - Execute a "noirq resume" callback for given device. > * @dev: Device to handle. > * @state: PM transition of the system being carried out. > * @async: If true, the device is being resumed asynchronously. > @@ -1077,7 +1077,7 @@ static pm_message_t resume_event(pm_mess > } > > /** > - * device_suspend_noirq - Execute a "late suspend" callback for given device. > + * __device_suspend_noirq - Execute a "noirq suspend" callback for given > device. > * @dev: Device to handle. > * @state: PM transition of the system being carried out. > * @async: If true, the device is being suspended asynchronously. > @@ -1237,7 +1237,7 @@ int dpm_suspend_noirq(pm_message_t state > } > > /** > - * device_suspend_late - Execute a "late suspend" callback for given device. > + * __device_suspend_late - Execute a "late suspend" callback for given > device. > * @dev: Device to handle. > * @state: PM transition of the system being carried out. > * @async: If true, the device is being suspended asynchronously. > @@ -1439,7 +1439,7 @@ static void dpm_clear_suppliers_direct_c > } > > /** > - * device_suspend - Execute "suspend" callbacks for given device. > + * __device_suspend - Execute "suspend" callbacks for given device. > * @dev: Device to handle. > * @state: PM transition of the system being carried out. > * @async: If true, the device is being suspended asynchronously. > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] mm, thp: introduce dedicated transparent huge page allocation interfaces
From: Changbin Du
The first one introduce new interfaces, the second one kills naming confusion.
The aim is to remove duplicated code and simplify transparent huge page
allocation.
Changbin Du (2):
mm, thp: introduce dedicated transparent huge page allocation
interfaces
mm: rename page dtor functions to {compound,huge,transhuge}_page__dtor
Documentation/vm/hugetlbfs_reserv.txt | 4 +--
include/linux/gfp.h | 4 ---
include/linux/huge_mm.h | 15 --
include/linux/hugetlb.h | 2 +-
include/linux/migrate.h | 14 -
include/linux/mm.h| 8 +++---
mm/huge_memory.c | 54 +--
mm/hugetlb.c | 14 -
mm/khugepaged.c | 11 ++-
mm/mempolicy.c| 10 ++-
mm/migrate.c | 12 +++-
mm/page_alloc.c | 10 +++
mm/shmem.c| 6 ++--
mm/swap.c | 2 +-
mm/userfaultfd.c | 2 +-
15 files changed, 95 insertions(+), 73 deletions(-)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] mm, thp: introduce dedicated transparent huge page allocation interfaces
From: Changbin Du
This patch introduced 4 new interfaces to allocate a prepared
transparent huge page.
- alloc_transhuge_page_vma
- alloc_transhuge_page_nodemask
- alloc_transhuge_page_node
- alloc_transhuge_page
The aim is to remove duplicated code and simplify transparent
huge page allocation. These are similar to alloc_hugepage_xxx
which are for hugetlbfs pages. This patch does below changes:
- define alloc_transhuge_page_xxx interfaces
- apply them to all existing code
- declare prep_transhuge_page as static since no others use it
- remove alloc_hugepage_vma definition since it no longer has users
Signed-off-by: Changbin Du
---
include/linux/gfp.h | 4
include/linux/huge_mm.h | 13 -
include/linux/migrate.h | 14 +-
mm/huge_memory.c| 50 ++---
mm/khugepaged.c | 11 ++-
mm/mempolicy.c | 10 +++---
mm/migrate.c| 12
mm/shmem.c | 6 ++
8 files changed, 71 insertions(+), 49 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index f780718..855c72e 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -507,15 +507,11 @@ alloc_pages(gfp_t gfp_mask, unsigned int order)
extern struct page *alloc_pages_vma(gfp_t gfp_mask, int order,
struct vm_area_struct *vma, unsigned long addr,
int node, bool hugepage);
-#define alloc_hugepage_vma(gfp_mask, vma, addr, order) \
- alloc_pages_vma(gfp_mask, order, vma, addr, numa_node_id(), true)
#else
#define alloc_pages(gfp_mask, order) \
alloc_pages_node(numa_node_id(), gfp_mask, order)
#define alloc_pages_vma(gfp_mask, order, vma, addr, node, false)\
alloc_pages(gfp_mask, order)
-#define alloc_hugepage_vma(gfp_mask, vma, addr, order) \
- alloc_pages(gfp_mask, order)
#endif
#define alloc_page(gfp_mask) alloc_pages(gfp_mask, 0)
#define alloc_page_vma(gfp_mask, vma, addr)\
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 14bc21c..1dd2c33 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -130,9 +130,20 @@ extern unsigned long thp_get_unmapped_area(struct file
*filp,
unsigned long addr, unsigned long len, unsigned long pgoff,
unsigned long flags);
-extern void prep_transhuge_page(struct page *page);
extern void free_transhuge_page(struct page *page);
+struct page *alloc_transhuge_page_vma(gfp_t gfp_mask,
+ struct vm_area_struct *vma, unsigned long addr);
+struct page *alloc_transhuge_page_nodemask(gfp_t gfp_mask,
+ int preferred_nid, nodemask_t *nmask);
+
+static inline struct page *alloc_transhuge_page_node(int nid, gfp_t gfp_mask)
+{
+ return alloc_transhuge_page_nodemask(gfp_mask, nid, NULL);
+}
+
+struct page *alloc_transhuge_page(gfp_t gfp_mask);
+
bool can_split_huge_page(struct page *page, int *pextra_pins);
int split_huge_page_to_list(struct page *page, struct list_head *list);
static inline int split_huge_page(struct page *page)
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index 643c7ae..70a00f3 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -42,19 +42,15 @@ static inline struct page *new_page_nodemask(struct page
*page,
return
alloc_huge_page_nodemask(page_hstate(compound_head(page)),
preferred_nid, nodemask);
- if (thp_migration_supported() && PageTransHuge(page)) {
- order = HPAGE_PMD_ORDER;
- gfp_mask |= GFP_TRANSHUGE;
- }
-
if (PageHighMem(page) || (zone_idx(page_zone(page)) == ZONE_MOVABLE))
gfp_mask |= __GFP_HIGHMEM;
- new_page = __alloc_pages_nodemask(gfp_mask, order,
+ if (thp_migration_supported() && PageTransHuge(page))
+ return alloc_transhuge_page_nodemask(gfp_mask | GFP_TRANSHUGE,
+ preferred_nid, nodemask);
+ else
+ return __alloc_pages_nodemask(gfp_mask, order,
preferred_nid, nodemask);
-
- if (new_page && PageTransHuge(page))
- prep_transhuge_page(new_page);
return new_page;
}
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 269b5df..e267488 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -490,7 +490,7 @@ static inline struct list_head *page_deferred_list(struct
page *page)
return (struct list_head *)&page[2].mapping;
}
-void prep_transhuge_page(struct page *page)
+static void prep_transhuge_page(struct page *page)
{
/*
* we use page->mapping and page->indexlru in second tail page
@@ -501,6 +501,45 @@ void prep_transhuge_page(struct page *page)
set_compound_page_dtor(page, TRANSHUGE_PAGE_DTOR);
}
+struct page *alloc_transhuge_page_vma(gfp_t gfp_mask,
+ struct vm_area_stru
[PATCH 2/2] mm: rename page dtor functions to {compound,huge,transhuge}_page__dtor
From: Changbin Du
The current name free_{huge,transhuge}_page are paired with
alloc_{huge,transhuge}_page functions, but the actual page free
function is still free_page() which will indirectly call
free_{huge,transhuge}_page. So this patch removes this confusion
by renaming all the compound page dtors.
Signed-off-by: Changbin Du
---
Documentation/vm/hugetlbfs_reserv.txt | 4 ++--
include/linux/huge_mm.h | 2 +-
include/linux/hugetlb.h | 2 +-
include/linux/mm.h| 8
mm/huge_memory.c | 4 ++--
mm/hugetlb.c | 14 +++---
mm/page_alloc.c | 10 +-
mm/swap.c | 2 +-
mm/userfaultfd.c | 2 +-
9 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/Documentation/vm/hugetlbfs_reserv.txt
b/Documentation/vm/hugetlbfs_reserv.txt
index 9aca09a..b3ffa3e 100644
--- a/Documentation/vm/hugetlbfs_reserv.txt
+++ b/Documentation/vm/hugetlbfs_reserv.txt
@@ -238,7 +238,7 @@ to the global reservation count (resv_huge_pages).
Freeing Huge Pages
--
-Huge page freeing is performed by the routine free_huge_page(). This routine
+Huge page freeing is performed by the routine huge_page_dtor(). This routine
is the destructor for hugetlbfs compound pages. As a result, it is only
passed a pointer to the page struct. When a huge page is freed, reservation
accounting may need to be performed. This would be the case if the page was
@@ -468,7 +468,7 @@ However, there are several instances where errors are
encountered after a huge
page is allocated but before it is instantiated. In this case, the page
allocation has consumed the reservation and made the appropriate subpool,
reservation map and global count adjustments. If the page is freed at this
-time (before instantiation and clearing of PagePrivate), then free_huge_page
+time (before instantiation and clearing of PagePrivate), then huge_page_dtor
will increment the global reservation count. However, the reservation map
indicates the reservation was consumed. This resulting inconsistent state
will cause the 'leak' of a reserved huge page. The global reserve count will
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 1dd2c33..40ae3058 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -130,7 +130,7 @@ extern unsigned long thp_get_unmapped_area(struct file
*filp,
unsigned long addr, unsigned long len, unsigned long pgoff,
unsigned long flags);
-extern void free_transhuge_page(struct page *page);
+extern void transhuge_page_dtor(struct page *page);
struct page *alloc_transhuge_page_vma(gfp_t gfp_mask,
struct vm_area_struct *vma, unsigned long addr);
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 8bbbd37..24492c5 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -118,7 +118,7 @@ long hugetlb_unreserve_pages(struct inode *inode, long
start, long end,
long freed);
bool isolate_huge_page(struct page *page, struct list_head *list);
void putback_active_hugepage(struct page *page);
-void free_huge_page(struct page *page);
+void huge_page_dtor(struct page *page);
void hugetlb_fix_reserve_counts(struct inode *inode);
extern struct mutex *hugetlb_fault_mutex_table;
u32 hugetlb_fault_mutex_hash(struct hstate *h, struct mm_struct *mm,
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 065d99d..adfa906 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -616,7 +616,7 @@ void split_page(struct page *page, unsigned int order);
* prototype for that function and accessor functions.
* These are _only_ valid on the head of a compound page.
*/
-typedef void compound_page_dtor(struct page *);
+typedef void compound_page_dtor_t(struct page *);
/* Keep the enum in sync with compound_page_dtors array in mm/page_alloc.c */
enum compound_dtor_id {
@@ -630,7 +630,7 @@ enum compound_dtor_id {
#endif
NR_COMPOUND_DTORS,
};
-extern compound_page_dtor * const compound_page_dtors[];
+extern compound_page_dtor_t * const compound_page_dtors[];
static inline void set_compound_page_dtor(struct page *page,
enum compound_dtor_id compound_dtor)
@@ -639,7 +639,7 @@ static inline void set_compound_page_dtor(struct page *page,
page[1].compound_dtor = compound_dtor;
}
-static inline compound_page_dtor *get_compound_page_dtor(struct page *page)
+static inline compound_page_dtor_t *get_compound_page_dtor(struct page *page)
{
VM_BUG_ON_PAGE(page[1].compound_dtor >= NR_COMPOUND_DTORS, page);
return compound_page_dtors[page[1].compound_dtor];
@@ -657,7 +657,7 @@ static inline void set_compound_order(struct page *page,
unsigned int order)
page[1].compound_order = order;
}
-void free_compound_page(struct page *page);
+
Re: [PATCH 8/8] Documentation: fix ref to gpio.txt
On Thu, Oct 12, 2017 at 10:24 PM, Tom Saeger wrote: > Signed-off-by: Tom Saeger Patch applied. Yours, Linus Walleij -- 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: Documentation: add Kernel Driver Statement to the kernel
On Sat, 14 Oct 2017, "gre...@linuxfoundation.org" wrote: > And really, all news one should be in correct markdown format, as it is > almost identical to a "normal" text file. Heck, it really is just a > "plain" textfile, you can read it as-such, right? *cough* reStructuredText *cough* BR, Jani. -- Jani Nikula, Intel Open Source Technology Center -- 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: rcu kernel-doc issues (4.14-rc1)
Hi Jonathan and Paul, Please include these fixes before 4.14 final. Thanks. On 09/17/17 12:49, Paul E. McKenney wrote: > On Sun, Sep 17, 2017 at 10:57:42AM -0700, Randy Dunlap wrote: >> On 09/17/17 10:47, Paul E. McKenney wrote: >>> On Sat, Sep 16, 2017 at 09:41:45PM -0700, Paul E. McKenney wrote: On Sat, Sep 16, 2017 at 06:26:04PM -0700, Randy Dunlap wrote: > On 4.14-rc1, I am seeing lots of warnings on rcu kernel-doc: > > .. kernel-doc:: include/linux/rcupdate.h >:external: > ./Documentation/core-api/kernel-api.rst:357: ERROR: Error in "kernel-doc" > directive: > unknown option: "external". $ grep external include/linux/rcupdate.h * by a single external-to-structure RCU-protected pointer, then you may * external-to-structure pointer -after- you have completely initialized Do these comments somehow qualify as an "external" option? If so, how do I tell kernel-doc to ignore them? Or must I reword them to avoid the word "external"? > .. kernel-doc:: include/linux/rcupdate_wait.h >:external: > ./Documentation/core-api/kernel-api.rst:360: ERROR: Error in "kernel-doc" > directive: > unknown option: "external". $ grep external include/linux/rcupdate_wait.h There is no occurrence of the string "external" in this file. So this "external" option is unknown to me as well. So, any hints on how I should interpret these error messages? >>> >>> And thanks to Akira Yokosawa for pointing out my confusion in reading >>> these error messages. The line numbers of course apply to the file >>> Documentation/core-api/kernel-api.rst rather than the various RCU >>> C-language source files. >>> >>> The patch below removes the error messages for me. Is this what you >>> had in mind? (Might need other options at some point, but somewhere >>> to start.) >>> >> >> Yes, much better. Thanks. >> >> Just some missing kernel-doc on parameters mostly remaining: > > I have now fixed a number of these, thank you. > > Any hints for how to represent code samples within a "/**" comment? > > /home/git/linux-2.6-tip/include/linux/rcupdate.h:559: ERROR: Unexpected > indentation. > /home/git/linux-2.6-tip/include/linux/rcupdate.h:563: WARNING: Block quote > ends without a blank line; unexpected unindent. > /home/git/linux-2.6-tip/include/linux/rcupdate.h:777: ERROR: Unexpected > indentation. > /home/git/linux-2.6-tip/include/linux/rcupdate.h:778: WARNING: Block quote > ends without a blank line; unexpected unindent. > > Thanx, Paul > >> ../include/linux/rcupdate.h:818: warning: No description found for parameter >> 'p' >> ../include/linux/rcupdate.h:818: warning: No description found for parameter >> 'v' >> ../include/linux/rcupdate.h:826: warning: No description found for parameter >> 'p' >> ../include/linux/rcupdate.h:826: warning: No description found for parameter >> 'v' >> ../include/linux/srcu.h:95: warning: No description found for parameter 'sp' >> ../kernel/rcu/srcutree.c:873: warning: No description found for parameter >> 'rhp' >> ../kernel/rcu/srcutree.c:873: warning: Excess function parameter 'head' >> description in 'call_srcu' >> ../include/linux/rculist.h:302: warning: Incorrect use of kernel-doc format: >> * list_first_or_null_rcu - get the first element from a list >> ../include/linux/rculist.h:317: warning: No description found for parameter >> 'ptr' >> ../include/linux/rculist.h:317: warning: No description found for parameter >> 'type' >> ../include/linux/rculist.h:317: warning: No description found for parameter >> 'member' >> ../kernel/rcu/sync.c:94: warning: No description found for parameter 'rsp' >> ../kernel/rcu/sync.c:162: warning: No description found for parameter 'rcu' >> ../kernel/rcu/sync.c:162: warning: Excess function parameter 'rsp' >> description in 'rcu_sync_func' >> >>> >>> >>> >>> diff --git a/Documentation/core-api/kernel-api.rst >>> b/Documentation/core-api/kernel-api.rst >>> index 8282099e0cbf..30b2666bf494 100644 >>> --- a/Documentation/core-api/kernel-api.rst >>> +++ b/Documentation/core-api/kernel-api.rst >>> @@ -352,44 +352,44 @@ Read-Copy Update (RCU) >>> -- >>> >>> .. kernel-doc:: include/linux/rcupdate.h >>> - :external: >>> + :export >>> >>> .. kernel-doc:: include/linux/rcupdate_wait.h >>> - :external: >>> + :export >>> >>> .. kernel-doc:: include/linux/rcutree.h >>> - :external: >>> + :export >>> >>> .. kernel-doc:: kernel/rcu/tree.c >>> - :external: >>> + :export >>> >>> .. kernel-doc:: kernel/rcu/tree_plugin.h >>> - :external: >>> + :export >>> >>> .. kernel-doc:: kernel/rcu/tree_exp.h >>> - :external: >>> + :export >>> >>> .. kernel-doc:: kernel/rcu/update.c >>> - :external: >>> + :export >>> >>> .. kernel-doc:: include/linux/src
Re: rcu kernel-doc issues (4.14-rc1)
On Mon, Oct 16, 2017 at 12:58:28PM -0700, Randy Dunlap wrote: > Hi Jonathan and Paul, > > Please include these fixes before 4.14 final. Hello, Randy, I currently have them queued up for the 4.15 merge window. Will that work for you? Thanx, Paul > Thanks. > > On 09/17/17 12:49, Paul E. McKenney wrote: > > On Sun, Sep 17, 2017 at 10:57:42AM -0700, Randy Dunlap wrote: > >> On 09/17/17 10:47, Paul E. McKenney wrote: > >>> On Sat, Sep 16, 2017 at 09:41:45PM -0700, Paul E. McKenney wrote: > On Sat, Sep 16, 2017 at 06:26:04PM -0700, Randy Dunlap wrote: > > On 4.14-rc1, I am seeing lots of warnings on rcu kernel-doc: > > > > .. kernel-doc:: include/linux/rcupdate.h > >:external: > > ./Documentation/core-api/kernel-api.rst:357: ERROR: Error in > > "kernel-doc" directive: > > unknown option: "external". > > $ grep external include/linux/rcupdate.h > * by a single external-to-structure RCU-protected pointer, then you may > * external-to-structure pointer -after- you have completely initialized > > Do these comments somehow qualify as an "external" option? If so, how > do I tell kernel-doc to ignore them? Or must I reword them to avoid > the word "external"? > > > .. kernel-doc:: include/linux/rcupdate_wait.h > >:external: > > ./Documentation/core-api/kernel-api.rst:360: ERROR: Error in > > "kernel-doc" directive: > > unknown option: "external". > > $ grep external include/linux/rcupdate_wait.h > > There is no occurrence of the string "external" in this file. So this > "external" option is unknown to me as well. So, any hints on how I > should interpret these error messages? > >>> > >>> And thanks to Akira Yokosawa for pointing out my confusion in reading > >>> these error messages. The line numbers of course apply to the file > >>> Documentation/core-api/kernel-api.rst rather than the various RCU > >>> C-language source files. > >>> > >>> The patch below removes the error messages for me. Is this what you > >>> had in mind? (Might need other options at some point, but somewhere > >>> to start.) > >>> > >> > >> Yes, much better. Thanks. > >> > >> Just some missing kernel-doc on parameters mostly remaining: > > > > I have now fixed a number of these, thank you. > > > > Any hints for how to represent code samples within a "/**" comment? > > > > /home/git/linux-2.6-tip/include/linux/rcupdate.h:559: ERROR: Unexpected > > indentation. > > /home/git/linux-2.6-tip/include/linux/rcupdate.h:563: WARNING: Block quote > > ends without a blank line; unexpected unindent. > > /home/git/linux-2.6-tip/include/linux/rcupdate.h:777: ERROR: Unexpected > > indentation. > > /home/git/linux-2.6-tip/include/linux/rcupdate.h:778: WARNING: Block quote > > ends without a blank line; unexpected unindent. > > > > Thanx, Paul > > > >> ../include/linux/rcupdate.h:818: warning: No description found for > >> parameter 'p' > >> ../include/linux/rcupdate.h:818: warning: No description found for > >> parameter 'v' > >> ../include/linux/rcupdate.h:826: warning: No description found for > >> parameter 'p' > >> ../include/linux/rcupdate.h:826: warning: No description found for > >> parameter 'v' > >> ../include/linux/srcu.h:95: warning: No description found for parameter > >> 'sp' > >> ../kernel/rcu/srcutree.c:873: warning: No description found for parameter > >> 'rhp' > >> ../kernel/rcu/srcutree.c:873: warning: Excess function parameter 'head' > >> description in 'call_srcu' > >> ../include/linux/rculist.h:302: warning: Incorrect use of kernel-doc > >> format: * list_first_or_null_rcu - get the first element from a list > >> ../include/linux/rculist.h:317: warning: No description found for > >> parameter 'ptr' > >> ../include/linux/rculist.h:317: warning: No description found for > >> parameter 'type' > >> ../include/linux/rculist.h:317: warning: No description found for > >> parameter 'member' > >> ../kernel/rcu/sync.c:94: warning: No description found for parameter 'rsp' > >> ../kernel/rcu/sync.c:162: warning: No description found for parameter 'rcu' > >> ../kernel/rcu/sync.c:162: warning: Excess function parameter 'rsp' > >> description in 'rcu_sync_func' > >> > >>> > >>> > >>> > >>> diff --git a/Documentation/core-api/kernel-api.rst > >>> b/Documentation/core-api/kernel-api.rst > >>> index 8282099e0cbf..30b2666bf494 100644 > >>> --- a/Documentation/core-api/kernel-api.rst > >>> +++ b/Documentation/core-api/kernel-api.rst > >>> @@ -352,44 +352,44 @@ Read-Copy Update (RCU) > >>> -- > >>> > >>> .. kernel-doc:: include/linux/rcupdate.h > >>> - :external: > >>> + :export > >>> > >>> .. kernel-doc:: include/linux/rcupdate_wait.h > >>> - :external: > >>> + :export > >>>
Re: [PATCH 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags
On Mon, 16 Oct 2017, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The motivation for this change is to provide a way to work around > a problem with the direct-complete mechanism used for avoiding > system suspend/resume handling for devices in runtime suspend. > > The problem is that some middle layer code (the PCI bus type and > the ACPI PM domain in particular) returns positive values from its > system suspend ->prepare callbacks regardless of whether the driver's > ->prepare returns a positive value or 0, which effectively prevents > drivers from being able to control the direct-complete feature. > Some drivers need that control, however, and the PCI bus type has > grown its own flag to deal with this issue, but since it is not > limited to PCI, it is better to address it by adding driver flags at > the core level. I'm curious: Why does the PCI bus type (and others) do this? Why doesn't it do what the driver says to do? Alan Stern -- 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: rcu kernel-doc issues (4.14-rc1)
On 10/16/17 13:07, Paul E. McKenney wrote: > On Mon, Oct 16, 2017 at 12:58:28PM -0700, Randy Dunlap wrote: >> Hi Jonathan and Paul, >> >> Please include these fixes before 4.14 final. > > Hello, Randy, > > I currently have them queued up for the 4.15 merge window. Will that > work for you? They should be fixed in 4.14 final IMO. > Thanx, Paul > >> Thanks. >> >> On 09/17/17 12:49, Paul E. McKenney wrote: >>> On Sun, Sep 17, 2017 at 10:57:42AM -0700, Randy Dunlap wrote: On 09/17/17 10:47, Paul E. McKenney wrote: > On Sat, Sep 16, 2017 at 09:41:45PM -0700, Paul E. McKenney wrote: >> On Sat, Sep 16, 2017 at 06:26:04PM -0700, Randy Dunlap wrote: >>> On 4.14-rc1, I am seeing lots of warnings on rcu kernel-doc: >>> >>> .. kernel-doc:: include/linux/rcupdate.h >>>:external: >>> ./Documentation/core-api/kernel-api.rst:357: ERROR: Error in >>> "kernel-doc" directive: >>> unknown option: "external". >> >> $ grep external include/linux/rcupdate.h >> * by a single external-to-structure RCU-protected pointer, then you may >> * external-to-structure pointer -after- you have completely initialized >> >> Do these comments somehow qualify as an "external" option? If so, how >> do I tell kernel-doc to ignore them? Or must I reword them to avoid >> the word "external"? >> >>> .. kernel-doc:: include/linux/rcupdate_wait.h >>>:external: >>> ./Documentation/core-api/kernel-api.rst:360: ERROR: Error in >>> "kernel-doc" directive: >>> unknown option: "external". >> >> $ grep external include/linux/rcupdate_wait.h >> >> There is no occurrence of the string "external" in this file. So this >> "external" option is unknown to me as well. So, any hints on how I >> should interpret these error messages? > > And thanks to Akira Yokosawa for pointing out my confusion in reading > these error messages. The line numbers of course apply to the file > Documentation/core-api/kernel-api.rst rather than the various RCU > C-language source files. > > The patch below removes the error messages for me. Is this what you > had in mind? (Might need other options at some point, but somewhere > to start.) > Yes, much better. Thanks. Just some missing kernel-doc on parameters mostly remaining: >>> >>> I have now fixed a number of these, thank you. >>> >>> Any hints for how to represent code samples within a "/**" comment? >>> >>> /home/git/linux-2.6-tip/include/linux/rcupdate.h:559: ERROR: Unexpected >>> indentation. >>> /home/git/linux-2.6-tip/include/linux/rcupdate.h:563: WARNING: Block quote >>> ends without a blank line; unexpected unindent. >>> /home/git/linux-2.6-tip/include/linux/rcupdate.h:777: ERROR: Unexpected >>> indentation. >>> /home/git/linux-2.6-tip/include/linux/rcupdate.h:778: WARNING: Block quote >>> ends without a blank line; unexpected unindent. >>> >>> Thanx, Paul >>> ../include/linux/rcupdate.h:818: warning: No description found for parameter 'p' ../include/linux/rcupdate.h:818: warning: No description found for parameter 'v' ../include/linux/rcupdate.h:826: warning: No description found for parameter 'p' ../include/linux/rcupdate.h:826: warning: No description found for parameter 'v' ../include/linux/srcu.h:95: warning: No description found for parameter 'sp' ../kernel/rcu/srcutree.c:873: warning: No description found for parameter 'rhp' ../kernel/rcu/srcutree.c:873: warning: Excess function parameter 'head' description in 'call_srcu' ../include/linux/rculist.h:302: warning: Incorrect use of kernel-doc format: * list_first_or_null_rcu - get the first element from a list ../include/linux/rculist.h:317: warning: No description found for parameter 'ptr' ../include/linux/rculist.h:317: warning: No description found for parameter 'type' ../include/linux/rculist.h:317: warning: No description found for parameter 'member' ../kernel/rcu/sync.c:94: warning: No description found for parameter 'rsp' ../kernel/rcu/sync.c:162: warning: No description found for parameter 'rcu' ../kernel/rcu/sync.c:162: warning: Excess function parameter 'rsp' description in 'rcu_sync_func' > > > > diff --git a/Documentation/core-api/kernel-api.rst > b/Documentation/core-api/kernel-api.rst > index 8282099e0cbf..30b2666bf494 100644 > --- a/Documentation/core-api/kernel-api.rst > +++ b/Documentation/core-api/kernel-api.rst > @@ -352,44 +352,44 @@ Read-Copy Update (RCU) > -- > > .. kernel-doc:: include/linux/rcupdate.h > - :external: > + :export > >
Re: rcu kernel-doc issues (4.14-rc1)
On Mon, Oct 16, 2017 at 01:18:14PM -0700, Randy Dunlap wrote: > On 10/16/17 13:07, Paul E. McKenney wrote: > > On Mon, Oct 16, 2017 at 12:58:28PM -0700, Randy Dunlap wrote: > >> Hi Jonathan and Paul, > >> > >> Please include these fixes before 4.14 final. > > > > Hello, Randy, > > > > I currently have them queued up for the 4.15 merge window. Will that > > work for you? > > They should be fixed in 4.14 final IMO. OK, how about if I submit them to the 4.15 merge window, but add the appropriate -stable tags to get them backported? Yes, these are bugs, but I cannot in good conscience claim that they are v4.14 regressions. But if Jon agrees with you, I will of course create a patch series, pull request, or whatever and send it along to him. Thanx, Paul > >> Thanks. > >> > >> On 09/17/17 12:49, Paul E. McKenney wrote: > >>> On Sun, Sep 17, 2017 at 10:57:42AM -0700, Randy Dunlap wrote: > On 09/17/17 10:47, Paul E. McKenney wrote: > > On Sat, Sep 16, 2017 at 09:41:45PM -0700, Paul E. McKenney wrote: > >> On Sat, Sep 16, 2017 at 06:26:04PM -0700, Randy Dunlap wrote: > >>> On 4.14-rc1, I am seeing lots of warnings on rcu kernel-doc: > >>> > >>> .. kernel-doc:: include/linux/rcupdate.h > >>>:external: > >>> ./Documentation/core-api/kernel-api.rst:357: ERROR: Error in > >>> "kernel-doc" directive: > >>> unknown option: "external". > >> > >> $ grep external include/linux/rcupdate.h > >> * by a single external-to-structure RCU-protected pointer, then you > >> may > >> * external-to-structure pointer -after- you have completely > >> initialized > >> > >> Do these comments somehow qualify as an "external" option? If so, how > >> do I tell kernel-doc to ignore them? Or must I reword them to avoid > >> the word "external"? > >> > >>> .. kernel-doc:: include/linux/rcupdate_wait.h > >>>:external: > >>> ./Documentation/core-api/kernel-api.rst:360: ERROR: Error in > >>> "kernel-doc" directive: > >>> unknown option: "external". > >> > >> $ grep external include/linux/rcupdate_wait.h > >> > >> There is no occurrence of the string "external" in this file. So this > >> "external" option is unknown to me as well. So, any hints on how I > >> should interpret these error messages? > > > > And thanks to Akira Yokosawa for pointing out my confusion in reading > > these error messages. The line numbers of course apply to the file > > Documentation/core-api/kernel-api.rst rather than the various RCU > > C-language source files. > > > > The patch below removes the error messages for me. Is this what you > > had in mind? (Might need other options at some point, but somewhere > > to start.) > > > > Yes, much better. Thanks. > > Just some missing kernel-doc on parameters mostly remaining: > >>> > >>> I have now fixed a number of these, thank you. > >>> > >>> Any hints for how to represent code samples within a "/**" comment? > >>> > >>> /home/git/linux-2.6-tip/include/linux/rcupdate.h:559: ERROR: Unexpected > >>> indentation. > >>> /home/git/linux-2.6-tip/include/linux/rcupdate.h:563: WARNING: Block > >>> quote ends without a blank line; unexpected unindent. > >>> /home/git/linux-2.6-tip/include/linux/rcupdate.h:777: ERROR: Unexpected > >>> indentation. > >>> /home/git/linux-2.6-tip/include/linux/rcupdate.h:778: WARNING: Block > >>> quote ends without a blank line; unexpected unindent. > >>> > >>> Thanx, Paul > >>> > ../include/linux/rcupdate.h:818: warning: No description found for > parameter 'p' > ../include/linux/rcupdate.h:818: warning: No description found for > parameter 'v' > ../include/linux/rcupdate.h:826: warning: No description found for > parameter 'p' > ../include/linux/rcupdate.h:826: warning: No description found for > parameter 'v' > ../include/linux/srcu.h:95: warning: No description found for parameter > 'sp' > ../kernel/rcu/srcutree.c:873: warning: No description found for > parameter 'rhp' > ../kernel/rcu/srcutree.c:873: warning: Excess function parameter 'head' > description in 'call_srcu' > ../include/linux/rculist.h:302: warning: Incorrect use of kernel-doc > format: * list_first_or_null_rcu - get the first element from a list > ../include/linux/rculist.h:317: warning: No description found for > parameter 'ptr' > ../include/linux/rculist.h:317: warning: No description found for > parameter 'type' > ../include/linux/rculist.h:317: warning: No description found for > parameter 'member' > ../kernel/rcu/sync.c:94: warning: No description found for parameter > 'rsp' > ../kernel/rcu/sync.c:162: warning: No description found for parameter > 'rcu' > ../ker
Re: rcu kernel-doc issues (4.14-rc1)
On 10/16/17 13:26, Paul E. McKenney wrote: > On Mon, Oct 16, 2017 at 01:18:14PM -0700, Randy Dunlap wrote: >> On 10/16/17 13:07, Paul E. McKenney wrote: >>> On Mon, Oct 16, 2017 at 12:58:28PM -0700, Randy Dunlap wrote: Hi Jonathan and Paul, Please include these fixes before 4.14 final. >>> >>> Hello, Randy, >>> >>> I currently have them queued up for the 4.15 merge window. Will that >>> work for you? >> >> They should be fixed in 4.14 final IMO. > > OK, how about if I submit them to the 4.15 merge window, but add the > appropriate -stable tags to get them backported? Yes, these are bugs, > but I cannot in good conscience claim that they are v4.14 regressions. > > But if Jon agrees with you, I will of course create a patch series, > pull request, or whatever and send it along to him. You or Jon could just revert this commit then: commit 764f80798b958f74dbf0c6e76a8294d183dd9c16 Author: Paul E. McKenney Date: Tue Jul 4 14:42:20 2017 -0700 doc: Add RCU files to docbook-generation files Suggested-by: Jonathan Corbet Signed-off-by: Paul E. McKenney But the current condition is bad. > Thanx, Paul > Thanks. On 09/17/17 12:49, Paul E. McKenney wrote: > On Sun, Sep 17, 2017 at 10:57:42AM -0700, Randy Dunlap wrote: >> On 09/17/17 10:47, Paul E. McKenney wrote: >>> On Sat, Sep 16, 2017 at 09:41:45PM -0700, Paul E. McKenney wrote: On Sat, Sep 16, 2017 at 06:26:04PM -0700, Randy Dunlap wrote: > On 4.14-rc1, I am seeing lots of warnings on rcu kernel-doc: > > .. kernel-doc:: include/linux/rcupdate.h >:external: > ./Documentation/core-api/kernel-api.rst:357: ERROR: Error in > "kernel-doc" directive: > unknown option: "external". $ grep external include/linux/rcupdate.h * by a single external-to-structure RCU-protected pointer, then you may * external-to-structure pointer -after- you have completely initialized Do these comments somehow qualify as an "external" option? If so, how do I tell kernel-doc to ignore them? Or must I reword them to avoid the word "external"? > .. kernel-doc:: include/linux/rcupdate_wait.h >:external: > ./Documentation/core-api/kernel-api.rst:360: ERROR: Error in > "kernel-doc" directive: > unknown option: "external". $ grep external include/linux/rcupdate_wait.h There is no occurrence of the string "external" in this file. So this "external" option is unknown to me as well. So, any hints on how I should interpret these error messages? >>> >>> And thanks to Akira Yokosawa for pointing out my confusion in reading >>> these error messages. The line numbers of course apply to the file >>> Documentation/core-api/kernel-api.rst rather than the various RCU >>> C-language source files. >>> >>> The patch below removes the error messages for me. Is this what you >>> had in mind? (Might need other options at some point, but somewhere >>> to start.) >>> >> >> Yes, much better. Thanks. >> >> Just some missing kernel-doc on parameters mostly remaining: > > I have now fixed a number of these, thank you. > > Any hints for how to represent code samples within a "/**" comment? > > /home/git/linux-2.6-tip/include/linux/rcupdate.h:559: ERROR: Unexpected > indentation. > /home/git/linux-2.6-tip/include/linux/rcupdate.h:563: WARNING: Block > quote ends without a blank line; unexpected unindent. > /home/git/linux-2.6-tip/include/linux/rcupdate.h:777: ERROR: Unexpected > indentation. > /home/git/linux-2.6-tip/include/linux/rcupdate.h:778: WARNING: Block > quote ends without a blank line; unexpected unindent. > > Thanx, Paul > >> ../include/linux/rcupdate.h:818: warning: No description found for >> parameter 'p' >> ../include/linux/rcupdate.h:818: warning: No description found for >> parameter 'v' >> ../include/linux/rcupdate.h:826: warning: No description found for >> parameter 'p' >> ../include/linux/rcupdate.h:826: warning: No description found for >> parameter 'v' >> ../include/linux/srcu.h:95: warning: No description found for parameter >> 'sp' >> ../kernel/rcu/srcutree.c:873: warning: No description found for >> parameter 'rhp' >> ../kernel/rcu/srcutree.c:873: warning: Excess function parameter 'head' >> description in 'call_srcu' >> ../include/linux/rculist.h:302: warning: Incorrect use of kernel-doc >> format: * list_first_or_null_rcu - get the first element from a list >> ../include/linux/rculist.h:317: warning: No description found for >> parameter 'ptr' >>
Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume
On Mon, Oct 16, 2017 at 9:08 AM, Greg Kroah-Hartman wrote: > On Mon, Oct 16, 2017 at 03:12:35AM +0200, Rafael J. Wysocki wrote: >> Hi All, >> >> Well, this took more time than expected, as I tried to cover everything I had >> in mind regarding PM flags for drivers. >> >> This work was triggered by attempts to fix and optimize PM in the >> i2c-designware-platdev driver that ended up with adding a couple of >> flags to the driver's internal data structures for the tracking of >> device state (https://marc.info/?l=linux-acpi&m=150629646805636&w=2). >> That approach is sort of suboptimal, though, because other drivers will >> probably want to do similar things and if all of them need to use internal >> flags for that, quite a bit of code duplication may ensue at least. >> >> That can be avoided in a couple of ways and one of them is to provide a means >> for drivers to tell the core what to do and to make the core take care of it >> if told to do so. Hence, the idea to use driver flags for system-wide PM >> that was briefly discussed during the LPC in LA last month. >> >> One of the flags considered at that time was to possibly cause the core >> to reuse the runtime PM callback path of a device for system suspend/resume. >> Admittedly, that idea didn't look too bad to me until I had started to try to >> implement it and I got to the PCI bus type's hibernation callbacks. Then, I >> moved the patch I was working on to /dev/null right away. I mean it. >> >> No, this is not going to happen. No way. >> >> Moreover, that experience made me realize that the whole *idea* of using the >> runtime PM callback path for system-wide PM was actually totally bogus (sorry >> Ulf). >> >> The whole point of having different callbacks pointers for different types of >> device transitions is because it may be necessary to do different things in >> those callbacks in general. Now, if you consider runtime PM and system >> suspend/resume *only* and from a driver perspective, then yes, in some cases >> the same pair of callback routines may be used for all suspend-like and >> resume-like transitions of the device, but if you add hibernation to the mix, >> then it is not so clear any more unless the callbacks don't actually do any >> power management at all, but simply quiesce the device's activity and then >> activate it again. Namely, changing power states of devices during the >> hibernation's "freeze" and "thaw" transitions rarely makes sense at all and >> the "restore" transition needs to be able to cope with uninitialized devices >> (in fact, it should be prepared to cope with devices in *any* state), so >> runtime PM is hardly suitable for them. Still, if a *driver* choses to not >> do any real PM in its PM callbacks and leaves that to a middle layer (quite >> a few drivers do that), then it possibly can use one pair of callbacks in all >> cases and be happy, but middle layers pretty much have to use different >> callback routines for different transitions. >> >> If you are a middle layer, your role is basically to do PM for a certain >> group of devices. Thus you cannot really do the same in ->suspend or >> ->suspend_early and in ->runtime_suspend (because the former generally need >> to >> take device_may_wakeup() into account and the latter doesn't) and you >> shouldn't >> really do the same in ->suspend and ->freeze (becuase the latter shouldn't >> change the device's power state) and so on. To put it bluntly, trying >> to use the ->runtime_suspend callback of a middle layer for anything other >> than runtime suspend is complete and utter nonsense. At the same time, the >> ->runtime_resume callback of a middle layer may be reused to some extent, >> but even that doesn't cover the "thaw" transitions during hibernation. >> >> What can work (and this is the only strategy that can work AFAICS) is to >> point different callback pointers *in* *a* *driver* to the same routine >> if the driver wants to reuse that code. That actually will work for PCI >> and USB drivers today, at least most of the time, but unfortunately there >> are problems with it for, say, platform devices. >> >> The first problem is the requirement to track the status of the device >> (suspended vs not suspended) in the callbacks, because the system-wide PM >> code in the PM core doesn't do that. The runtime PM framework does it, so >> this means adding some extra code which isn't necessary for runtime PM to >> the callback routines and that is not particularly nice. >> >> The second problem is that, if the driver wants to do anything in its >> ->suspend callback, it generally has to prevent runtime suspend of the >> device from taking place in parallel with that, which is quite cumbersome. >> Usually, that is taken care of by resuming the device from runtime suspend >> upfront, but generally doing that is wasteful (there may be no real need to >> resume the device except for the fact that the code is designed this way). >> >> On top of the above,
Re: [PATCH 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags
On Monday, October 16, 2017 7:34:52 AM CEST Lukas Wunner wrote: > On Mon, Oct 16, 2017 at 03:29:02AM +0200, Rafael J. Wysocki wrote: > > + :c:func:`dev_pm_set_driver_flags` helper function.] If the first of > > + tese flags is set, the PM core will not apply the direct-complete > ^ > these > > > + proceudre described above to the given device and, consequenty, to any > ^ > procedure > Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags
On Monday, October 16, 2017 8:28:52 AM CEST Greg Kroah-Hartman wrote:
> On Mon, Oct 16, 2017 at 03:29:02AM +0200, Rafael J. Wysocki wrote:
> > struct dev_pm_info {
> > pm_message_tpower_state;
> > unsigned intcan_wakeup:1;
> > @@ -561,6 +580,7 @@ struct dev_pm_info {
> > boolis_late_suspended:1;
> > boolearly_init:1; /* Owned by the PM core */
> > booldirect_complete:1; /* Owned by the PM core
> > */
> > + unsigned intdriver_flags;
>
> Minor nit, u32 or u64?
u32 I think, will update.
BTW, there's a mess in this struct overall and I'd like all of the bit fileds
to be the same type (and that shouldn't be bool IMO :-)).
Do you prefer u32 or unsinged int?
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags
On Monday, October 16, 2017 8:31:22 AM CEST Greg Kroah-Hartman wrote:
> On Mon, Oct 16, 2017 at 03:29:02AM +0200, Rafael J. Wysocki wrote:
> > +static inline void dev_pm_set_driver_flags(struct device *dev, unsigned
> > int flags)
> > +{
> > + dev->power.driver_flags = flags;
> > +}
>
> Should this function just set the specific bit? Or is it going to be ok
> to set the whole value, meaning you aren't going to care about turning
> on and off specific flags over the lifetime of the driver/device, you
> are just going to set them once and then just test them as needed?
The idea is to set them once and they should not be touched again until
the driver (or device) goes away, so that would be the whole value at once
(and one of the i2c-designware-platdrv patches actually sets multiple flags
in one go).
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags
On Monday, October 16, 2017 10:16:15 PM CEST Alan Stern wrote: > On Mon, 16 Oct 2017, Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki > > > > The motivation for this change is to provide a way to work around > > a problem with the direct-complete mechanism used for avoiding > > system suspend/resume handling for devices in runtime suspend. > > > > The problem is that some middle layer code (the PCI bus type and > > the ACPI PM domain in particular) returns positive values from its > > system suspend ->prepare callbacks regardless of whether the driver's > > ->prepare returns a positive value or 0, which effectively prevents > > drivers from being able to control the direct-complete feature. > > Some drivers need that control, however, and the PCI bus type has > > grown its own flag to deal with this issue, but since it is not > > limited to PCI, it is better to address it by adding driver flags at > > the core level. > > I'm curious: Why does the PCI bus type (and others) do this? Why > doesn't it do what the driver says to do? Well, the idea was that it might work for the existing drivers without the need to modify them (and they would have had to be modified had the driver's ->prepare return value been required to be taken into account). It actually does work for them in general, although with some notable exceptions. Thanks, Rafael -- 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] media: rga: make some functions static
drivers/media/platform/rockchip/rga/rga-hw.c:383:6: warning: no previous
prototype for 'rga_cmd_set' [-Wmissing-prototypes]
void rga_cmd_set(struct rga_ctx *ctx)
^~~
drivers/media/platform/rockchip/rga/rga.c:359:17: warning: no previous
prototype for 'rga_fmt_find' [-Wmissing-prototypes]
struct rga_fmt *rga_fmt_find(struct v4l2_format *f)
^~~~
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/platform/rockchip/rga/rga-hw.c | 2 +-
drivers/media/platform/rockchip/rga/rga.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/rockchip/rga/rga-hw.c
b/drivers/media/platform/rockchip/rga/rga-hw.c
index 0645481c9a5e..96d1b1b3fe8e 100644
--- a/drivers/media/platform/rockchip/rga/rga-hw.c
+++ b/drivers/media/platform/rockchip/rga/rga-hw.c
@@ -380,7 +380,7 @@ static void rga_cmd_set_mode(struct rga_ctx *ctx)
dest[(RGA_MODE_CTRL - RGA_MODE_BASE_REG) >> 2] = mode.val;
}
-void rga_cmd_set(struct rga_ctx *ctx)
+static void rga_cmd_set(struct rga_ctx *ctx)
{
struct rockchip_rga *rga = ctx->rga;
diff --git a/drivers/media/platform/rockchip/rga/rga.c
b/drivers/media/platform/rockchip/rga/rga.c
index 2cf3bb29a2b3..e7d1b34baf1c 100644
--- a/drivers/media/platform/rockchip/rga/rga.c
+++ b/drivers/media/platform/rockchip/rga/rga.c
@@ -356,7 +356,7 @@ struct rga_fmt formats[] = {
#define NUM_FORMATS ARRAY_SIZE(formats)
-struct rga_fmt *rga_fmt_find(struct v4l2_format *f)
+static struct rga_fmt *rga_fmt_find(struct v4l2_format *f)
{
unsigned int i;
--
2.13.6
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] documentation: kernel-api: add more info on bitmap functions
From: Randy Dunlap There are some good comments about bitmap operations in lib/bitmap.c and include/linux/bitmap.h, so format them for document generation and pull them into core-api/kernel-api.rst. I converted the "tables" of functions from using tabs to using spaces so that they are more readable in the source file and in the generated output. Signed-off-by: Randy Dunlap --- Documentation/core-api/kernel-api.rst | 12 ++ include/linux/bitmap.h| 105 +--- lib/bitmap.c |4 3 files changed, 72 insertions(+), 49 deletions(-) --- lnx-414-rc5.orig/include/linux/bitmap.h +++ lnx-414-rc5/include/linux/bitmap.h @@ -21,65 +21,74 @@ * See lib/bitmap.c for more details. */ -/* +/** + * DOC: bitmap overview + * * The available bitmap operations and their rough meaning in the * case that the bitmap is a single unsigned long are thus: * * Note that nbits should be always a compile time evaluable constant. * Otherwise many inlines will generate horrible code. * - * bitmap_zero(dst, nbits) *dst = 0UL - * bitmap_fill(dst, nbits) *dst = ~0UL - * bitmap_copy(dst, src, nbits)*dst = *src - * bitmap_and(dst, src1, src2, nbits) *dst = *src1 & *src2 - * bitmap_or(dst, src1, src2, nbits) *dst = *src1 | *src2 - * bitmap_xor(dst, src1, src2, nbits) *dst = *src1 ^ *src2 - * bitmap_andnot(dst, src1, src2, nbits) *dst = *src1 & ~(*src2) - * bitmap_complement(dst, src, nbits) *dst = ~(*src) - * bitmap_equal(src1, src2, nbits) Are *src1 and *src2 equal? - * bitmap_intersects(src1, src2, nbits)Do *src1 and *src2 overlap? - * bitmap_subset(src1, src2, nbits)Is *src1 a subset of *src2? - * bitmap_empty(src, nbits)Are all bits zero in *src? - * bitmap_full(src, nbits) Are all bits set in *src? - * bitmap_weight(src, nbits) Hamming Weight: number set bits - * bitmap_set(dst, pos, nbits) Set specified bit area - * bitmap_clear(dst, pos, nbits) Clear specified bit area - * bitmap_find_next_zero_area(buf, len, pos, n, mask) Find bit free area - * bitmap_find_next_zero_area_off(buf, len, pos, n, mask) as above - * bitmap_shift_right(dst, src, n, nbits) *dst = *src >> n - * bitmap_shift_left(dst, src, n, nbits) *dst = *src << n - * bitmap_remap(dst, src, old, new, nbits) *dst = map(old, new)(src) - * bitmap_bitremap(oldbit, old, new, nbits)newbit = map(old, new)(oldbit) - * bitmap_onto(dst, orig, relmap, nbits) *dst = orig relative to relmap - * bitmap_fold(dst, orig, sz, nbits) dst bits = orig bits mod sz - * bitmap_parse(buf, buflen, dst, nbits) Parse bitmap dst from kernel buf - * bitmap_parse_user(ubuf, ulen, dst, nbits) Parse bitmap dst from user buf - * bitmap_parselist(buf, dst, nbits) Parse bitmap dst from kernel buf - * bitmap_parselist_user(buf, dst, nbits) Parse bitmap dst from user buf - * bitmap_find_free_region(bitmap, bits, order)Find and allocate bit region - * bitmap_release_region(bitmap, pos, order) Free specified bit region - * bitmap_allocate_region(bitmap, pos, order) Allocate specified bit region - * bitmap_from_u32array(dst, nbits, buf, nwords) *dst = *buf (nwords 32b words) - * bitmap_to_u32array(buf, nwords, src, nbits) *buf = *dst (nwords 32b words) + * :: + * + * bitmap_zero(dst, nbits) *dst = 0UL + * bitmap_fill(dst, nbits) *dst = ~0UL + * bitmap_copy(dst, src, nbits)*dst = *src + * bitmap_and(dst, src1, src2, nbits) *dst = *src1 & *src2 + * bitmap_or(dst, src1, src2, nbits) *dst = *src1 | *src2 + * bitmap_xor(dst, src1, src2, nbits) *dst = *src1 ^ *src2 + * bitmap_andnot(dst, src1, src2, nbits) *dst = *src1 & ~(*src2) + * bitmap_complement(dst, src, nbits) *dst = ~(*src) + * bitmap_equal(src1, src2, nbits) Are *src1 and *src2 equal? + * bitmap_intersects(src1, src2, nbits)Do *src1 and *src2 overlap? + * bitmap_subset(src1, src2, nbits)Is *src1 a subset of *src2? + * bitmap_empty(src, nbits)Are all bits zero in *src? + * bitmap_full(src, nbits) Are all bits set in *src? + * bitmap_weight(src, nbits) Hamming Weight: number set bits + * bitmap_set(dst, pos, nbits) Set specified bit area + * bitmap_clear(dst, pos, nbits) Clear specified bit area + * bitmap_find_next_zero_area(buf, len, pos, n, mask) Find bit free area + * bitmap_find_next_zero_area_off(buf, len, pos, n, mask) as above + * bitmap_shift_right(dst, src, n, nbits) *dst = *src >> n + * bitmap_shift_left(dst, src, n, nbits) *dst = *src << n + * bitmap_remap(dst, src, old, new, nbits) *dst = map(old, new)(src) + * bitm
Re: rcu kernel-doc issues (4.14-rc1)
On Mon, Oct 16, 2017 at 02:46:15PM -0700, Randy Dunlap wrote: > On 10/16/17 13:26, Paul E. McKenney wrote: > > On Mon, Oct 16, 2017 at 01:18:14PM -0700, Randy Dunlap wrote: > >> On 10/16/17 13:07, Paul E. McKenney wrote: > >>> On Mon, Oct 16, 2017 at 12:58:28PM -0700, Randy Dunlap wrote: > Hi Jonathan and Paul, > > Please include these fixes before 4.14 final. > >>> > >>> Hello, Randy, > >>> > >>> I currently have them queued up for the 4.15 merge window. Will that > >>> work for you? > >> > >> They should be fixed in 4.14 final IMO. > > > > OK, how about if I submit them to the 4.15 merge window, but add the > > appropriate -stable tags to get them backported? Yes, these are bugs, > > but I cannot in good conscience claim that they are v4.14 regressions. > > > > But if Jon agrees with you, I will of course create a patch series, > > pull request, or whatever and send it along to him. > > You or Jon could just revert this commit then: > > commit 764f80798b958f74dbf0c6e76a8294d183dd9c16 > Author: Paul E. McKenney > Date: Tue Jul 4 14:42:20 2017 -0700 > > doc: Add RCU files to docbook-generation files > > Suggested-by: Jonathan Corbet > Signed-off-by: Paul E. McKenney > > But the current condition is bad. Jon, what would you prefer? Thanx, Paul > Thanks. > > On 09/17/17 12:49, Paul E. McKenney wrote: > > On Sun, Sep 17, 2017 at 10:57:42AM -0700, Randy Dunlap wrote: > >> On 09/17/17 10:47, Paul E. McKenney wrote: > >>> On Sat, Sep 16, 2017 at 09:41:45PM -0700, Paul E. McKenney wrote: > On Sat, Sep 16, 2017 at 06:26:04PM -0700, Randy Dunlap wrote: > > On 4.14-rc1, I am seeing lots of warnings on rcu kernel-doc: > > > > .. kernel-doc:: include/linux/rcupdate.h > >:external: > > ./Documentation/core-api/kernel-api.rst:357: ERROR: Error in > > "kernel-doc" directive: > > unknown option: "external". > > $ grep external include/linux/rcupdate.h > * by a single external-to-structure RCU-protected pointer, then you > may > * external-to-structure pointer -after- you have completely > initialized > > Do these comments somehow qualify as an "external" option? If so, > how > do I tell kernel-doc to ignore them? Or must I reword them to avoid > the word "external"? > > > .. kernel-doc:: include/linux/rcupdate_wait.h > >:external: > > ./Documentation/core-api/kernel-api.rst:360: ERROR: Error in > > "kernel-doc" directive: > > unknown option: "external". > > $ grep external include/linux/rcupdate_wait.h > > There is no occurrence of the string "external" in this file. So > this > "external" option is unknown to me as well. So, any hints on how I > should interpret these error messages? > >>> > >>> And thanks to Akira Yokosawa for pointing out my confusion in reading > >>> these error messages. The line numbers of course apply to the file > >>> Documentation/core-api/kernel-api.rst rather than the various RCU > >>> C-language source files. > >>> > >>> The patch below removes the error messages for me. Is this what you > >>> had in mind? (Might need other options at some point, but somewhere > >>> to start.) > >>> > >> > >> Yes, much better. Thanks. > >> > >> Just some missing kernel-doc on parameters mostly remaining: > > > > I have now fixed a number of these, thank you. > > > > Any hints for how to represent code samples within a "/**" comment? > > > > /home/git/linux-2.6-tip/include/linux/rcupdate.h:559: ERROR: Unexpected > > indentation. > > /home/git/linux-2.6-tip/include/linux/rcupdate.h:563: WARNING: Block > > quote ends without a blank line; unexpected unindent. > > /home/git/linux-2.6-tip/include/linux/rcupdate.h:777: ERROR: Unexpected > > indentation. > > /home/git/linux-2.6-tip/include/linux/rcupdate.h:778: WARNING: Block > > quote ends without a blank line; unexpected unindent. > > > > Thanx, Paul > > > >> ../include/linux/rcupdate.h:818: warning: No description found for > >> parameter 'p' > >> ../include/linux/rcupdate.h:818: warning: No description found for > >> parameter 'v' > >> ../include/linux/rcupdate.h:826: warning: No description found for > >> parameter 'p' > >> ../include/linux/rcupdate.h:826: warning: No description found for > >> parameter 'v' > >> ../include/linux/srcu.h:95: warning: No description found for > >> parameter 'sp' > >> ../kernel/rcu/srcutree.c:873: warning: No description found for > >> parameter 'rhp' > >> ../kernel/rcu/srcut
