Re: [PATCH v2 6/7] ocxl: Add an IOCTL so userspace knows what CPU features are available
On Tue, 2018-05-08 at 13:50 +1000, Nicholas Piggin wrote: > On Tue, 08 May 2018 10:41:55 +1000 > "Alastair D'Silva"wrote: > > > On Mon, 2018-05-07 at 20:14 +0200, Frederic Barrat wrote: > > > > > > Le 18/04/2018 à 03:08, Alastair D'Silva a écrit : > > > > From: Alastair D'Silva > > > > > > > > In order for a userspace AFU driver to call the Power9 specific > > > > OCXL_IOCTL_ENABLE_P9_WAIT, it needs to verify that it can > > > > actually > > > > make that call. > > > > > > > > Signed-off-by: Alastair D'Silva > > > > --- > > > > Documentation/accelerators/ocxl.rst | 1 - > > > > drivers/misc/ocxl/file.c| 25 > > > > + > > > > include/uapi/misc/ocxl.h| 4 > > > > 3 files changed, 29 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/Documentation/accelerators/ocxl.rst > > > > b/Documentation/accelerators/ocxl.rst > > > > index ddcc58d01cfb..7904adcc07fd 100644 > > > > --- a/Documentation/accelerators/ocxl.rst > > > > +++ b/Documentation/accelerators/ocxl.rst > > > > @@ -157,7 +157,6 @@ OCXL_IOCTL_GET_METADATA: > > > > Obtains configuration information from the card, such at > > > > the > > > > size of > > > > MMIO areas, the AFU version, and the PASID for the current > > > > context. > > > > > > > > - > > > > > > > > > Intended? > > > > > > Other than that, > > > Acked-by: Frederic Barrat > > > > > > > Nope, I'll fix that, thanks. > > > > Just to be clear, this is for OCXL features. I would just make that > explicit in the title (s/CPU/OCXL). > > Thanks, > Nick > OK, sounds reasonable. -- Alastair D'Silva Open Source Developer Linux Technology Centre, IBM Australia mob: 0423 762 819 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/7] ocxl: Add an IOCTL so userspace knows what CPU features are available
On Tue, 08 May 2018 10:41:55 +1000 "Alastair D'Silva"wrote: > On Mon, 2018-05-07 at 20:14 +0200, Frederic Barrat wrote: > > > > Le 18/04/2018 à 03:08, Alastair D'Silva a écrit : > > > From: Alastair D'Silva > > > > > > In order for a userspace AFU driver to call the Power9 specific > > > OCXL_IOCTL_ENABLE_P9_WAIT, it needs to verify that it can actually > > > make that call. > > > > > > Signed-off-by: Alastair D'Silva > > > --- > > > Documentation/accelerators/ocxl.rst | 1 - > > > drivers/misc/ocxl/file.c| 25 > > > + > > > include/uapi/misc/ocxl.h| 4 > > > 3 files changed, 29 insertions(+), 1 deletion(-) > > > > > > diff --git a/Documentation/accelerators/ocxl.rst > > > b/Documentation/accelerators/ocxl.rst > > > index ddcc58d01cfb..7904adcc07fd 100644 > > > --- a/Documentation/accelerators/ocxl.rst > > > +++ b/Documentation/accelerators/ocxl.rst > > > @@ -157,7 +157,6 @@ OCXL_IOCTL_GET_METADATA: > > > Obtains configuration information from the card, such at the > > > size of > > > MMIO areas, the AFU version, and the PASID for the current > > > context. > > > > > > - > > > > > > Intended? > > > > Other than that, > > Acked-by: Frederic Barrat > > > > Nope, I'll fix that, thanks. > Just to be clear, this is for OCXL features. I would just make that explicit in the title (s/CPU/OCXL). Thanks, Nick -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] powerpc: Add TIDR CPU feature for Power9
On Mon, 2018-05-07 at 19:17 +0200, Frederic Barrat wrote: > > Le 18/04/2018 à 03:08, Alastair D'Silva a écrit : > > From: Alastair D'Silva> > > > This patch adds a CPU feature bit to show whether the CPU has > > the TIDR register available, enabling as_notify/wait in userspace. > > > > Signed-off-by: Alastair D'Silva > > --- > > arch/powerpc/include/asm/cputable.h | 3 ++- > > arch/powerpc/kernel/dt_cpu_ftrs.c | 1 + > > 2 files changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/arch/powerpc/include/asm/cputable.h > > b/arch/powerpc/include/asm/cputable.h > > index 4e332f3531c5..54c4cbbe57b4 100644 > > --- a/arch/powerpc/include/asm/cputable.h > > +++ b/arch/powerpc/include/asm/cputable.h > > @@ -215,6 +215,7 @@ static inline void cpu_feature_keys_init(void) > > { } > > #define CPU_FTR_P9_TM_HV_ASSIST LONG_ASM_CONST(0x0 > > 0001000) > > #define CPU_FTR_P9_TM_XER_SO_BUG LONG_ASM_CONST(0x2000 > > ) > > #define CPU_FTR_P9_TLBIE_BUG LONG_ASM_CONST(0x > > 4000) > > +#define CPU_FTR_P9_TIDRLONG_ASM_CONST(0x00 > > 008000) > > > > #ifndef __ASSEMBLY__ > > > > @@ -462,7 +463,7 @@ static inline void cpu_feature_keys_init(void) > > { } > > CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY | \ > > CPU_FTR_DBELL | CPU_FTR_HAS_PPR | CPU_FTR_ARCH_207S | > > \ > > CPU_FTR_TM_COMP | CPU_FTR_ARCH_300 | CPU_FTR_PKEY | \ > > - CPU_FTR_P9_TLBIE_BUG) > > + CPU_FTR_P9_TLBIE_BUG | CPU_FTR_P9_TIDR) > > #define CPU_FTRS_POWER9_DD1 ((CPU_FTRS_POWER9 | > > CPU_FTR_POWER9_DD1) & \ > > (~CPU_FTR_SAO)) > > #define CPU_FTRS_POWER9_DD2_0 CPU_FTRS_POWER9 > > diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c > > b/arch/powerpc/kernel/dt_cpu_ftrs.c > > index 11a3a4fed3fb..10f8b7f55637 100644 > > --- a/arch/powerpc/kernel/dt_cpu_ftrs.c > > +++ b/arch/powerpc/kernel/dt_cpu_ftrs.c > > @@ -722,6 +722,7 @@ static __init void cpufeatures_cpu_quirks(void) > > if ((version & 0x) == 0x004e) { > > cur_cpu_spec->cpu_features &= ~(CPU_FTR_DAWR); > > cur_cpu_spec->cpu_features |= > > CPU_FTR_P9_TLBIE_BUG; > + cur_cpu_spec->cpu_features > > |= CPU_FTR_P9_TIDR; > > > Isn't it redundant with adding the flag to CPU_FTRS_POWER9? > >Fred > No, cpu_features is populated from device tree, not from CPU_FTRS_POWER9. Since TIDR will not be explicitly requested in the device tree, we need to handle it in quirks. -- Alastair D'Silva Open Source Developer Linux Technology Centre, IBM Australia mob: 0423 762 819 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/18] docs: */index.rst: Add newer documents to their respective index.rst
On Mon, May 07, 2018 at 06:35:39AM -0300, Mauro Carvalho Chehab wrote: > A number of new docs were added, but they're currently not on > the index.rst from the session they're supposed to be, causing > Sphinx warnings. > > Add them. > > Signed-off-by: Mauro Carvalho ChehabReviewed-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/18] docs: driver-api: add clk documentation
On Mon, May 07, 2018 at 06:35:44AM -0300, Mauro Carvalho Chehab wrote: > The clk.rst is already in ReST format. So, move it to the > driver-api guide, where it belongs. > > Signed-off-by: Mauro Carvalho ChehabReviewed-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/18] docs: fix location of request_firmware & friends
On Mon, May 07, 2018 at 06:35:38AM -0300, Mauro Carvalho Chehab wrote: > commit 5d6d1ddd2730 ("firmware: move firmware loader into its own directory") > and other commits renamed the old firmware_class.c file and split it > into separate files, but documentation was not changed accordingly, > causing Sphinx errors. > > Change the location accordingly at the documentation files. > > While here, add a missing entry at request_firmware.rst for > release_firmware() function. > > Fixes: 5d6d1ddd2730 ("firmware: move firmware loader into its own directory") > Cc: Kees Cook> Cc: Luis R. Rodriguez > Cc: Greg Kroah-Hartman > Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 17/18] docs: uio-howto.rst: use a code block to solve a warning
On Mon, May 07, 2018 at 06:35:53AM -0300, Mauro Carvalho Chehab wrote: > /devel/v4l/docs/Documentation/driver-api/uio-howto.rst:715: WARNING: > Unexpected indentation. > > Signed-off-by: Mauro Carvalho ChehabReviewed-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/7] ocxl: Add an IOCTL so userspace knows what CPU features are available
On Mon, 2018-05-07 at 20:14 +0200, Frederic Barrat wrote: > > Le 18/04/2018 à 03:08, Alastair D'Silva a écrit : > > From: Alastair D'Silva> > > > In order for a userspace AFU driver to call the Power9 specific > > OCXL_IOCTL_ENABLE_P9_WAIT, it needs to verify that it can actually > > make that call. > > > > Signed-off-by: Alastair D'Silva > > --- > > Documentation/accelerators/ocxl.rst | 1 - > > drivers/misc/ocxl/file.c| 25 > > + > > include/uapi/misc/ocxl.h| 4 > > 3 files changed, 29 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/accelerators/ocxl.rst > > b/Documentation/accelerators/ocxl.rst > > index ddcc58d01cfb..7904adcc07fd 100644 > > --- a/Documentation/accelerators/ocxl.rst > > +++ b/Documentation/accelerators/ocxl.rst > > @@ -157,7 +157,6 @@ OCXL_IOCTL_GET_METADATA: > > Obtains configuration information from the card, such at the > > size of > > MMIO areas, the AFU version, and the PASID for the current > > context. > > > > - > > > Intended? > > Other than that, > Acked-by: Frederic Barrat > Nope, I'll fix that, thanks. -- Alastair D'Silva Open Source Developer Linux Technology Centre, IBM Australiamob: 0423 762 819 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/7] powerpc: use task_pid_nr() for TID allocation
On Mon, 2018-05-07 at 19:37 +0200, Frederic Barrat wrote: > > Le 18/04/2018 à 03:08, Alastair D'Silva a écrit : > > From: Alastair D'Silva> > > > The current implementation of TID allocation, using a global IDR, > > may > > result in an errant process starving the system of available TIDs. > > Instead, use task_pid_nr(), as mentioned by the original author. > > The > > scenario described which prevented it's use is not applicable, as > > set_thread_tidr can only be called after the task struct has been > > populated. > > > Here is how I understand what's going to happen if 2 threads are > using > the same TIDR value, which is possible with this patch (if unlikely): > > 1. waking up the wrong thread is not really a problem, as threads > have > to handle spurious wake up from the 'wait' instruction anyway, and > must > be using some other condition to know when to loop around the 'wait' > instruction. > > 2. missing the right thread: if the wrong thread is on a CPU, and a > wake_host_thread/as_notify is sent, the core will see a matching > thread > and will accept the command. The (open)capi adapter won't send an > interrupt. The wrong thread is awaken, which is not a problem as > discussed above. As the right thread to notify is not running, no > harm > is done either: as soon as the thread runs, it's supposed to check > its > condition (which will be met) or call 'wait', but 'wait' immediately > returns when called the first time after a thread is scheduled. > > So I believe we are ok. But I think it requires a huge comment with > the > above (at the minimum) :-) > > With a comment: > Reviewed-by: Frederic Barrat > >Fred > Good point, I'll add this in the next revision. -- Alastair D'Silva Open Source Developer Linux Technology Centre, IBM Australiamob: 0423 762 819 -- 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 v7 3/5] cpuset: Add a root-only cpus.isolated v2 control file
On 05/02/2018 10:08 AM, Peter Zijlstra wrote: > On Thu, Apr 19, 2018 at 09:47:02AM -0400, Waiman Long wrote: >> diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt >> index c970bd7..8d89dc2 100644 >> --- a/Documentation/cgroup-v2.txt >> +++ b/Documentation/cgroup-v2.txt >> @@ -1484,6 +1484,31 @@ Cpuset Interface Files >> a subset of "cpuset.cpus". Its value will be affected by CPU >> hotplug events. >> >> + cpuset.cpus.isolated >> +A read-write multiple values file which exists on root cgroup >> +only. >> + >> +It lists the CPUs that have been withdrawn from the root cgroup >> +for load balancing. These CPUs can still be allocated to child >> +cpusets with load balancing enabled, if necessary. >> + >> +If a child cpuset contains only an exclusive set of CPUs that are >> +a subset of the isolated CPUs and with load balancing enabled, >> +these CPUs will be load balanced on a separate root domain from >> +the one in the root cgroup. >> + >> +Just putting the CPUs into "cpuset.cpus.isolated" will be >> +enough to disable load balancing on those CPUs as long as they >> +do not appear in a child cpuset with load balancing enabled. >> +Fine-grained control of cpu isolation can also be done by >> +putting these isolated CPUs into child cpusets with load >> +balancing disabled. >> + >> +The "cpuset.cpus.isolated" should be set up before child >> +cpusets are created. Once child cpusets are present, changes >> +to "cpuset.cpus.isolated" will not be allowed if the CPUs that >> +change their states are in any of the child cpusets. >> + > So I see why you did this, but it is _really_ ugly and breaks the > container invariant. > > Ideally we'd make the root group less special, not more special. Yes, I am planning to make the root cgroup less special by putting a new isolation flag into all the non-root cgroup. The container invariant thing, however, is a bit hard to do. Do we really need a container root to behave exactly like the real root? I guess we can make that happen if we really want to, but it will certainly make the code more complex. So it is a trade-off about what is worth to do and what is not. Cheers, Longman -- 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 v7 3/4] ipc: Allow boot time extension of IPCMNI from 32k to 2M
On 05/07/2018 07:17 PM, Luis R. Rodriguez wrote: > On Mon, May 07, 2018 at 04:59:11PM -0400, Waiman Long wrote: >> diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c >> index 49f9bf4..d62335f 100644 >> --- a/ipc/ipc_sysctl.c >> +++ b/ipc/ipc_sysctl.c >> @@ -120,7 +120,8 @@ static int proc_ipc_sem_dointvec(struct ctl_table >> *table, int write, >> static int zero; >> static int one = 1; >> static int int_max = INT_MAX; >> -static int ipc_mni = IPCMNI; >> +int ipc_mni __read_mostly = IPCMNI; >> +int ipc_mni_shift __read_mostly = IPCMNI_SHIFT; >> >> static struct ctl_table ipc_kern_table[] = { >> { > Is use of ipc_mni and ipc_mni_shift a hot path? As per Christoph Lameter, > its use should be reserved for data that is actually used frequently in hot > paths, and typically this was done after performance traces reveal contention > because a neighboring variable was frequently written to [0]. These would also > be tightly packed, to reduce the number of cachelines needed to execute a > critical path, so we should be selective about what variables use it. > > Your commit log does not describe why you'd use __read_mostly here. It would > be useful if it did. > > [0] https://lkml.kernel.org/r/alpine.deb.2.11.1504301343190.28...@gentwo.org I used __read_mostly to reduce the performance impact of transitioning from a constant to a variable. But you are right, their use are probably not in a hot path. So even the use of regular variables shouldn't show any noticeable performance difference. I can take that out in the my next version after I gather enough feedback. Cheers, Longman -- 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 v7 1/4] ipc: IPCMNI limit check for msgmni and shmmni
On 05/07/2018 06:39 PM, Luis R. Rodriguez wrote: > On Mon, May 07, 2018 at 04:59:09PM -0400, Waiman Long wrote: >> A user can write arbitrary integer values to msgmni and shmmni sysctl >> parameters without getting error, but the actual limit is really >> IPCMNI (32k). This can mislead users as they think they can get a >> value that is not real. >> >> The right limits are now set for msgmni and shmmni so that the users >> will become aware if they set a value outside of the acceptable range. >> >> Signed-off-by: Waiman Long>> --- >> ipc/ipc_sysctl.c | 7 +-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c >> index 8ad93c2..f87cb29 100644 >> --- a/ipc/ipc_sysctl.c >> +++ b/ipc/ipc_sysctl.c >> @@ -99,6 +99,7 @@ static int proc_ipc_auto_msgmni(struct ctl_table *table, >> int write, >> static int zero; >> static int one = 1; >> static int int_max = INT_MAX; >> +static int ipc_mni = IPCMNI; >> >> static struct ctl_table ipc_kern_table[] = { >> { >> @@ -120,7 +121,9 @@ static int proc_ipc_auto_msgmni(struct ctl_table *table, >> int write, >> .data = _ipc_ns.shm_ctlmni, >> .maxlen = sizeof(init_ipc_ns.shm_ctlmni), >> .mode = 0644, >> -.proc_handler = proc_ipc_dointvec, >> +.proc_handler = proc_ipc_dointvec_minmax, >> +.extra1 = , >> +.extra2 = _mni, >> }, >> { >> .procname = "shm_rmid_forced", >> @@ -147,7 +150,7 @@ static int proc_ipc_auto_msgmni(struct ctl_table *table, >> int write, >> .mode = 0644, >> .proc_handler = proc_ipc_dointvec_minmax, >> .extra1 = , >> -.extra2 = _max, >> +.extra2 = _mni, >> }, >> { >> .procname = "auto_msgmni", >> -- >> 1.8.3.1 > It seems negative values are not allowed, if true then having > a caller to use proc_douintvec_minmax() would help with ensuring > no invalid negative input values are used as well. > > Luis Negative value doesn't mean sense here. So it is true that we can use proc_douintvec_minmax() instead. However, the data types themselves are defined as "int". So I think it is better to keep using proc_dointvec_minmax() to be consistent with the data type. Cheers, Longman -- 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 v7 3/4] ipc: Allow boot time extension of IPCMNI from 32k to 2M
On Mon, May 07, 2018 at 04:59:11PM -0400, Waiman Long wrote: > diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c > index 49f9bf4..d62335f 100644 > --- a/ipc/ipc_sysctl.c > +++ b/ipc/ipc_sysctl.c > @@ -120,7 +120,8 @@ static int proc_ipc_sem_dointvec(struct ctl_table *table, > int write, > static int zero; > static int one = 1; > static int int_max = INT_MAX; > -static int ipc_mni = IPCMNI; > +int ipc_mni __read_mostly = IPCMNI; > +int ipc_mni_shift __read_mostly = IPCMNI_SHIFT; > > static struct ctl_table ipc_kern_table[] = { > { Is use of ipc_mni and ipc_mni_shift a hot path? As per Christoph Lameter, its use should be reserved for data that is actually used frequently in hot paths, and typically this was done after performance traces reveal contention because a neighboring variable was frequently written to [0]. These would also be tightly packed, to reduce the number of cachelines needed to execute a critical path, so we should be selective about what variables use it. Your commit log does not describe why you'd use __read_mostly here. It would be useful if it did. [0] https://lkml.kernel.org/r/alpine.deb.2.11.1504301343190.28...@gentwo.org Luis -- 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 v7 1/4] ipc: IPCMNI limit check for msgmni and shmmni
On Mon, May 07, 2018 at 04:59:09PM -0400, Waiman Long wrote: > A user can write arbitrary integer values to msgmni and shmmni sysctl > parameters without getting error, but the actual limit is really > IPCMNI (32k). This can mislead users as they think they can get a > value that is not real. > > The right limits are now set for msgmni and shmmni so that the users > will become aware if they set a value outside of the acceptable range. > > Signed-off-by: Waiman Long> --- > ipc/ipc_sysctl.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c > index 8ad93c2..f87cb29 100644 > --- a/ipc/ipc_sysctl.c > +++ b/ipc/ipc_sysctl.c > @@ -99,6 +99,7 @@ static int proc_ipc_auto_msgmni(struct ctl_table *table, > int write, > static int zero; > static int one = 1; > static int int_max = INT_MAX; > +static int ipc_mni = IPCMNI; > > static struct ctl_table ipc_kern_table[] = { > { > @@ -120,7 +121,9 @@ static int proc_ipc_auto_msgmni(struct ctl_table *table, > int write, > .data = _ipc_ns.shm_ctlmni, > .maxlen = sizeof(init_ipc_ns.shm_ctlmni), > .mode = 0644, > - .proc_handler = proc_ipc_dointvec, > + .proc_handler = proc_ipc_dointvec_minmax, > + .extra1 = , > + .extra2 = _mni, > }, > { > .procname = "shm_rmid_forced", > @@ -147,7 +150,7 @@ static int proc_ipc_auto_msgmni(struct ctl_table *table, > int write, > .mode = 0644, > .proc_handler = proc_ipc_dointvec_minmax, > .extra1 = , > - .extra2 = _max, > + .extra2 = _mni, > }, > { > .procname = "auto_msgmni", > -- > 1.8.3.1 It seems negative values are not allowed, if true then having a caller to use proc_douintvec_minmax() would help with ensuring no invalid negative input values are used as well. Luis -- 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
coresight: documentation: update sysfs section
- Align and show updated ls devices output from the TC2, based on current driver - Provide an example from an ETMv4 based system (Juno) - Reflect changes to the way the RAM write pointer is accessed since it got changed in commit 7d83d17795ef ("coresight: tmc: adding sysFS management entries"). Cc: Mathieu PoirierCc: Jonathan Corbet Signed-off-by: Kim Phillips --- Documentation/trace/coresight.txt | 40 ++- 1 file changed, 24 insertions(+), 16 deletions(-) diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt index 6f0120c3a4f1..d23d6354b372 100644 --- a/Documentation/trace/coresight.txt +++ b/Documentation/trace/coresight.txt @@ -144,10 +144,21 @@ If everything goes well during the registration process the new devices will show up under /sys/bus/coresight/devices, as showns here for a TC2 platform: root:~# ls /sys/bus/coresight/devices/ -replicator 2003.tpiu2201c000.ptm 2203c000.etm 2203e000.etm -2001.etb 2004.funnel 2201d000.ptm 2203d000.etm +2001.etb 2004.funnel 2201d000.ptm 2203d000.etm replicator +2003.tpiu 2201c000.ptm2203c000.etm 2203e000.etm root:~# +and here for a Juno platform: + +root@juno:~# ls /sys/bus/coresight/devices/ +2001.etf2012.replicator 2204.etm 230c.funnel +2003.tpiu 2013.funnel 220c.funnel 2314.etm +2004.funnel 2014.etf2214.etm 2324.etm +2007.etr2015.funnel 2304.etm 2334.etm +root@juno:~# + +Note the Juno uses an Embedded Trace Router (ETR) instead of an ETB. + The functions take a "struct coresight_device", which looks like this: struct coresight_desc { @@ -193,16 +204,16 @@ the information carried in "THIS_MODULE". How to use the tracer modules - -Before trace collection can start, a coresight sink needs to be identify. +Before trace collection can start, a coresight sink needs to be identified. There is no limit on the amount of sinks (nor sources) that can be enabled at any given moment. As a generic operation, all device pertaining to the sink class will have an "active" entry in sysfs: root:/sys/bus/coresight/devices# ls -replicator 2003.tpiu2201c000.ptm 2203c000.etm 2203e000.etm -2001.etb 2004.funnel 2201d000.ptm 2203d000.etm +2001.etb 2004.funnel 2201d000.ptm 2203d000.etm replicator +2003.tpiu 2201c000.ptm2203c000.etm 2203e000.etm root:/sys/bus/coresight/devices# ls 2001.etb -enable_sink status trigger_cntr +enable_sink mgmt power subsystem trigger_cntr uevent root:/sys/bus/coresight/devices# echo 1 > 2001.etb/enable_sink root:/sys/bus/coresight/devices# cat 2001.etb/enable_sink 1 @@ -216,16 +227,13 @@ trigger a trace capture: root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source 1 -root:/sys/bus/coresight/devices# cat 2001.etb/status -Depth: 0x2000 -Status: 0x1 -RAM read ptr: 0x0 -RAM wrt ptr:0x19d3 <- The write pointer is moving -Trigger cnt:0x0 -Control:0x1 -Flush status: 0x0 -Flush ctrl: 0x2001 -root:/sys/bus/coresight/devices# + +Observe the write pointer moving: + +root:/sys/bus/coresight/devices# cat 2001.etb/mgmt/rwp +0x1a8 +root:/sys/bus/coresight/devices# cat 2001.etb/mgmt/rwp +0x19a6 Trace collection is stopped the same way: -- 2.17.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 2/4] ipc: IPCMNI limit check for semmni
For SysV semaphores, the semmni value is the last part of the 4-element sem number array. To make semmni behave in a similar way to msgmni and shmmni, we can't directly use the _minmax handler. Instead, a special sem specific handler is added to check the last argument to make sure that it is limited to the [0, IPCMNI] range. An error will be returned if this is not the case. Signed-off-by: Waiman Long--- ipc/ipc_sysctl.c | 23 ++- ipc/util.h | 9 + 2 files changed, 31 insertions(+), 1 deletion(-) diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c index f87cb29..49f9bf4 100644 --- a/ipc/ipc_sysctl.c +++ b/ipc/ipc_sysctl.c @@ -88,12 +88,33 @@ static int proc_ipc_auto_msgmni(struct ctl_table *table, int write, return proc_dointvec_minmax(_table, write, buffer, lenp, ppos); } +static int proc_ipc_sem_dointvec(struct ctl_table *table, int write, + void __user *buffer, size_t *lenp, loff_t *ppos) +{ + int ret, semmni; + struct ipc_namespace *ns = current->nsproxy->ipc_ns; + + semmni = ns->sem_ctls[3]; + ret = proc_ipc_dointvec(table, write, buffer, lenp, ppos); + + if (!ret) + ret = sem_check_semmni(current->nsproxy->ipc_ns); + + /* +* Reset the semmni value if an error happens. +*/ + if (ret) + ns->sem_ctls[3] = semmni; + return ret; +} + #else #define proc_ipc_doulongvec_minmax NULL #define proc_ipc_dointvec NULL #define proc_ipc_dointvec_minmax NULL #define proc_ipc_dointvec_minmax_orphans NULL #define proc_ipc_auto_msgmni NULL +#define proc_ipc_sem_dointvec NULL #endif static int zero; @@ -175,7 +196,7 @@ static int proc_ipc_auto_msgmni(struct ctl_table *table, int write, .data = _ipc_ns.sem_ctls, .maxlen = 4*sizeof(int), .mode = 0644, - .proc_handler = proc_ipc_dointvec, + .proc_handler = proc_ipc_sem_dointvec, }, #ifdef CONFIG_CHECKPOINT_RESTORE { diff --git a/ipc/util.h b/ipc/util.h index acc5159..8b413f1 100644 --- a/ipc/util.h +++ b/ipc/util.h @@ -218,6 +218,15 @@ int ipcget(struct ipc_namespace *ns, struct ipc_ids *ids, void free_ipcs(struct ipc_namespace *ns, struct ipc_ids *ids, void (*free)(struct ipc_namespace *, struct kern_ipc_perm *)); +static inline int sem_check_semmni(struct ipc_namespace *ns) { + /* +* Check semmni range [0, IPCMNI] +* semmni is the last element of sem_ctls[4] array +*/ + return ((ns->sem_ctls[3] < 0) || (ns->sem_ctls[3] > IPCMNI)) + ? -ERANGE : 0; +} + #ifdef CONFIG_COMPAT #include struct compat_ipc_perm { -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 1/4] ipc: IPCMNI limit check for msgmni and shmmni
A user can write arbitrary integer values to msgmni and shmmni sysctl parameters without getting error, but the actual limit is really IPCMNI (32k). This can mislead users as they think they can get a value that is not real. The right limits are now set for msgmni and shmmni so that the users will become aware if they set a value outside of the acceptable range. Signed-off-by: Waiman Long--- ipc/ipc_sysctl.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c index 8ad93c2..f87cb29 100644 --- a/ipc/ipc_sysctl.c +++ b/ipc/ipc_sysctl.c @@ -99,6 +99,7 @@ static int proc_ipc_auto_msgmni(struct ctl_table *table, int write, static int zero; static int one = 1; static int int_max = INT_MAX; +static int ipc_mni = IPCMNI; static struct ctl_table ipc_kern_table[] = { { @@ -120,7 +121,9 @@ static int proc_ipc_auto_msgmni(struct ctl_table *table, int write, .data = _ipc_ns.shm_ctlmni, .maxlen = sizeof(init_ipc_ns.shm_ctlmni), .mode = 0644, - .proc_handler = proc_ipc_dointvec, + .proc_handler = proc_ipc_dointvec_minmax, + .extra1 = , + .extra2 = _mni, }, { .procname = "shm_rmid_forced", @@ -147,7 +150,7 @@ static int proc_ipc_auto_msgmni(struct ctl_table *table, int write, .mode = 0644, .proc_handler = proc_ipc_dointvec_minmax, .extra1 = , - .extra2 = _max, + .extra2 = _mni, }, { .procname = "auto_msgmni", -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 3/4] ipc: Allow boot time extension of IPCMNI from 32k to 2M
The maximum number of unique System V IPC identifiers was limited to 32k. That limit should be big enough for most use cases. However, there are some users out there requesting for more. To satisfy the need of those users, a new boot time kernel option "ipcmni_extend" is added to extend the IPCMNI value to 2M. This is a 64X increase which hopefully is big enough for them. This new option does have the side effect of reducing the maximum number of unique sequence numbers from 64k down to 1k. So it is a trade-off. Signed-off-by: Waiman Long--- Documentation/admin-guide/kernel-parameters.txt | 3 ++ ipc/ipc_sysctl.c| 12 ++- ipc/util.c | 12 +++ ipc/util.h | 42 +++-- 4 files changed, 52 insertions(+), 17 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 11fc28e..00bc0cb 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1735,6 +1735,9 @@ ip= [IP_PNP] See Documentation/filesystems/nfs/nfsroot.txt. + ipcmni_extend [KNL] Extend the maximum number of unique System V + IPC identifiers from 32768 to 2097152. + irqaffinity=[SMP] Set the default irq affinity mask The argument is a cpu list, as described above. diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c index 49f9bf4..d62335f 100644 --- a/ipc/ipc_sysctl.c +++ b/ipc/ipc_sysctl.c @@ -120,7 +120,8 @@ static int proc_ipc_sem_dointvec(struct ctl_table *table, int write, static int zero; static int one = 1; static int int_max = INT_MAX; -static int ipc_mni = IPCMNI; +int ipc_mni __read_mostly = IPCMNI; +int ipc_mni_shift __read_mostly = IPCMNI_SHIFT; static struct ctl_table ipc_kern_table[] = { { @@ -246,3 +247,12 @@ static int __init ipc_sysctl_init(void) } device_initcall(ipc_sysctl_init); + +static int __init ipc_mni_extend(char *str) +{ + ipc_mni = IPCMNI_EXTEND; + ipc_mni_shift = IPCMNI_EXTEND_SHIFT; + pr_info("IPCMNI extended to %d.\n", ipc_mni); + return 0; +} +early_param("ipcmni_extend", ipc_mni_extend); diff --git a/ipc/util.c b/ipc/util.c index 4e81182..782a8d0 100644 --- a/ipc/util.c +++ b/ipc/util.c @@ -113,7 +113,7 @@ static int __init ipc_init(void) * @ids: ipc identifier set * * Set up the sequence range to use for the ipc identifier range (limited - * below IPCMNI) then initialise the keys hashtable and ids idr. + * below ipc_mni) then initialise the keys hashtable and ids idr. */ int ipc_init_ids(struct ipc_ids *ids) { @@ -214,7 +214,7 @@ static inline int ipc_buildid(int id, struct ipc_ids *ids, ids->next_id = -1; } - return SEQ_MULTIPLIER * new->seq + id; + return (new->seq << SEQ_SHIFT) + id; } #else @@ -228,7 +228,7 @@ static inline int ipc_buildid(int id, struct ipc_ids *ids, if (ids->seq > IPCID_SEQ_MAX) ids->seq = 0; - return SEQ_MULTIPLIER * new->seq + id; + return (new->seq << SEQ_SHIFT) + id; } #endif /* CONFIG_CHECKPOINT_RESTORE */ @@ -252,8 +252,8 @@ int ipc_addid(struct ipc_ids *ids, struct kern_ipc_perm *new, int limit) kgid_t egid; int id, err; - if (limit > IPCMNI) - limit = IPCMNI; + if (limit > ipc_mni) + limit = ipc_mni; if (!ids->tables_initialized || ids->in_use >= limit) return -ENOSPC; @@ -777,7 +777,7 @@ static struct kern_ipc_perm *sysvipc_find_ipc(struct ipc_ids *ids, loff_t pos, if (total >= ids->in_use) return NULL; - for (; pos < IPCMNI; pos++) { + for (; pos < ipc_mni; pos++) { ipc = idr_find(>ipcs_idr, pos); if (ipc != NULL) { *new_pos = pos + 1; diff --git a/ipc/util.h b/ipc/util.h index 8b413f1..9df177f 100644 --- a/ipc/util.h +++ b/ipc/util.h @@ -15,8 +15,30 @@ #include #include -#define IPCMNI 32768 /* <= MAX_INT limit for ipc arrays (including sysctl changes) */ -#define SEQ_MULTIPLIER (IPCMNI) +/* + * By default, the ipc arrays can have up to 32k (15 bits) entries. + * When IPCMNI extension mode is turned on, the ipc arrays can have up + * to 2M (21 bits) entries. However, the space for sequence number will + * be shrunk from 16 bits to 10 bits. + */ +#define IPCMNI_SHIFT 15 +#define IPCMNI_EXTEND_SHIFT21 +#define IPCMNI (1 << IPCMNI_SHIFT) +#define IPCMNI_EXTEND (1 << IPCMNI_EXTEND_SHIFT) + +#ifdef CONFIG_SYSVIPC_SYSCTL +extern int ipc_mni; +extern int ipc_mni_shift; + +#define SEQ_SHIFT ipc_mni_shift +#define SEQ_MASK ((1 << ipc_mni_shift) - 1) + +#else /* CONFIG_SYSVIPC_SYSCTL */ + +#define ipc_mni
[PATCH v7 4/4] ipc: Conserve sequence numbers in extended IPCMNI mode
The mixing in of a sequence number into the IPC IDs is probably to avoid ID reuse in userspace as much as possible. With extended IPCMNI mode, the number of usable sequence numbers is greatly reduced leading to higher chance of ID reuse. To address this issue, we need to conserve the sequence number space as much as possible. Right now, the sequence number is incremented for every new ID created. In reality, we only need to increment the sequence number when one or more IDs have been removed previously to make sure that those IDs will not be reused when a new one is built. This is being done in the extended IPCMNI mode, Signed-off-by: Waiman Long--- include/linux/ipc_namespace.h | 1 + ipc/ipc_sysctl.c | 2 ++ ipc/util.c| 29 ++--- ipc/util.h| 2 ++ 4 files changed, 27 insertions(+), 7 deletions(-) diff --git a/include/linux/ipc_namespace.h b/include/linux/ipc_namespace.h index b5630c8..9c86fd9 100644 --- a/include/linux/ipc_namespace.h +++ b/include/linux/ipc_namespace.h @@ -16,6 +16,7 @@ struct ipc_ids { int in_use; unsigned short seq; + unsigned short deleted; bool tables_initialized; struct rw_semaphore rwsem; struct idr ipcs_idr; diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c index d62335f..1d32941 100644 --- a/ipc/ipc_sysctl.c +++ b/ipc/ipc_sysctl.c @@ -122,6 +122,7 @@ static int proc_ipc_sem_dointvec(struct ctl_table *table, int write, static int int_max = INT_MAX; int ipc_mni __read_mostly = IPCMNI; int ipc_mni_shift __read_mostly = IPCMNI_SHIFT; +bool ipc_mni_extended __read_mostly; static struct ctl_table ipc_kern_table[] = { { @@ -252,6 +253,7 @@ static int __init ipc_mni_extend(char *str) { ipc_mni = IPCMNI_EXTEND; ipc_mni_shift = IPCMNI_EXTEND_SHIFT; + ipc_mni_extended = true; pr_info("IPCMNI extended to %d.\n", ipc_mni); return 0; } diff --git a/ipc/util.c b/ipc/util.c index 782a8d0..7c8e733 100644 --- a/ipc/util.c +++ b/ipc/util.c @@ -119,7 +119,8 @@ int ipc_init_ids(struct ipc_ids *ids) { int err; ids->in_use = 0; - ids->seq = 0; + ids->deleted = false; + ids->seq = ipc_mni_extended ? 0 : -1; /* seq # is pre-incremented */ init_rwsem(>rwsem); err = rhashtable_init(>key_ht, _kht_params); if (err) @@ -193,6 +194,11 @@ static struct kern_ipc_perm *ipc_findkey(struct ipc_ids *ids, key_t key) return NULL; } +/* + * To conserve sequence number space with extended ipc_mni when new ID + * is built, the sequence number is incremented only when one or more + * IDs have been removed previously. + */ #ifdef CONFIG_CHECKPOINT_RESTORE /* * Specify desired id for next allocated IPC object. @@ -206,9 +212,13 @@ static inline int ipc_buildid(int id, struct ipc_ids *ids, struct kern_ipc_perm *new) { if (ids->next_id < 0) { /* default, behave as !CHECKPOINT_RESTORE */ - new->seq = ids->seq++; - if (ids->seq > IPCID_SEQ_MAX) - ids->seq = 0; + if (!ipc_mni_extended || ids->deleted) { + ids->seq++; + if (ids->seq > IPCID_SEQ_MAX) + ids->seq = 0; + ids->deleted = false; + } + new->seq = ids->seq; } else { new->seq = ipcid_to_seqx(ids->next_id); ids->next_id = -1; @@ -224,9 +234,13 @@ static inline int ipc_buildid(int id, struct ipc_ids *ids, static inline int ipc_buildid(int id, struct ipc_ids *ids, struct kern_ipc_perm *new) { - new->seq = ids->seq++; - if (ids->seq > IPCID_SEQ_MAX) - ids->seq = 0; + if (!ipc_mni_extended || ids->deleted) { + ids->seq++; + if (ids->seq > IPCID_SEQ_MAX) + ids->seq = 0; + ids->deleted = false; + } + new->seq = ids->seq; return (new->seq << SEQ_SHIFT) + id; } @@ -436,6 +450,7 @@ void ipc_rmid(struct ipc_ids *ids, struct kern_ipc_perm *ipcp) idr_remove(>ipcs_idr, lid); ipc_kht_remove(ids, ipcp); ids->in_use--; + ids->deleted = true; ipcp->deleted = true; if (unlikely(lid == ids->max_id)) { diff --git a/ipc/util.h b/ipc/util.h index 9df177f..0ef381c 100644 --- a/ipc/util.h +++ b/ipc/util.h @@ -29,6 +29,7 @@ #ifdef CONFIG_SYSVIPC_SYSCTL extern int ipc_mni; extern int ipc_mni_shift; +extern bool ipc_mni_extended; #define SEQ_SHIFT ipc_mni_shift #define SEQ_MASK ((1 << ipc_mni_shift) - 1) @@ -36,6 +37,7 @@ #else /* CONFIG_SYSVIPC_SYSCTL */ #define ipc_mniIPCMNI +#define ipc_mni_extended false #define SEQ_SHIFT IPCMNI_SHIFT #define SEQ_MASK ((1 << IPCMNI_SHIFT)
[PATCH v7 0/4] ipc: IPCMNI limit check for *mni & increase that limit
v6->v7: - Drop the range clamping code and just return error instead for now until there is user request for clamping support. - Fix compilation error when CONFIG_SYSVIPC_SYSCTL isn't defined. v5->v6: - Consolidate the 3 ctl_table flags into 2. - Make similar changes to proc_doulongvec_minmax() and its associates to complete the clamping change. - Remove the sysctl registration failure test patch for now for later consideration. - Add extra braces to patch 1 to reduce code diff in a later patch. v4->v5: - Revert the flags back to 16-bit so that there will be no change to the size of ctl_table. - Enhance the sysctl_check_flags() as requested by Luis to perform more checks to spot incorrect ctl_table entries. - Change the sysctl selftest to use dummy sysctls instead of production ones & enhance it to do more checks. - Add one more sysctl selftest for registration failure. - Add 2 ipc patches to add an extended mode to increase IPCMNI from 32k to 2M. - Miscellaneous change to incorporate feedback comments from reviewers. v3->v4: - Remove v3 patches 1 & 2 as they have been merged into the mm tree. - Change flags from uint16_t to unsigned int. - Remove CTL_FLAGS_OOR_WARNED and use pr_warn_ratelimited() instead. - Simplify the warning message code. - Add a new patch to fail the ctl_table registration with invalid flag. - Add a test case for range clamping in sysctl selftest. v2->v3: - Fix kdoc comment errors. - Incorporate comments and suggestions from Luis R. Rodriguez. - Add a patch to fix a typo error in fs/proc/proc_sysctl.c. v1->v2: - Add kdoc comments to the do_proc_do{u}intvec_minmax_conv_param structures. - Add a new flags field to the ctl_table structure for specifying whether range clamping should be activated instead of adding new sysctl parameter handlers. - Clamp the semmni value embedded in the multi-values sem parameter. v4 patch: https://lkml.org/lkml/2018/3/12/867 v5 patch: https://lkml.org/lkml/2018/3/16/1106 v6 patch: https://lkml.org/lkml/2018/4/27/1094 The sysctl parameters msgmni, shmmni and semmni have an inherent limit of IPC_MNI (32k). However, users may not be aware of that because they can write a value much higher than that without getting any error or notification. Reading the parameters back will show the newly written values which are not real. The real IPCMNI limit is now enforced to make sure that users won't put in an unrealistic value. The first 2 patches enforce the limits. There are also users out there requesting increase in the IPCMNI value. The last 2 patches attempt to do that by using a boot kernel parameter "ipcmni_extend" to increase the IPCMNI limit from 32k to 2M if the users really want the extended value. Waiman Long (4): ipc: IPCMNI limit check for msgmni and shmmni ipc: IPCMNI limit check for semmni ipc: Allow boot time extension of IPCMNI from 32k to 2M ipc: Conserve sequence numbers in extended IPCMNI mode Documentation/admin-guide/kernel-parameters.txt | 3 ++ include/linux/ipc_namespace.h | 1 + ipc/ipc_sysctl.c| 42 +++-- ipc/util.c | 41 ++--- ipc/util.h | 49 + 5 files changed, 112 insertions(+), 24 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/8] ipc: Clamp *mni to the real IPCMNI limit & increase that limit
On 05/02/2018 11:06 AM, Eric W. Biederman wrote: > >>> and or users that may or may not exist. If you can find something that >>> will care sure. We need to avoid breaking userspace and causing >>> regressions. However as this stands it looks you are making maintenance >>> of the kernel more difficult to avoid having to look to see if there are >>> monsters under the bed. >> I shall admit that it can be hard to find applications that will >> explicitly need that as we usually don't have access to the applications >> that the customers have. It is more a correctness issue where the >> existing code is kind of lying about what can actually be supported. I >> just want to make the users more aware of what the right limits are. > You presume the kernel is lying to applications. I admit the kernel > can lie to applications. I don't see any evidence that the kernel is > actually doing so. So far (to me) it looks like a large number of sysv > shared memory segments is not particulalry common. > > So I would not be at all surprised if no regressions would be generated > if you simply deny setting the value past the maximum. Maybe you are right. I will update the patchset to fail the update if the range is exceeded since I had added option of extending the limit if the users choose to do so. Cheers, Longman -- 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/18] docs: can.rst: fix a footnote reference
+ Robert Schwebel (who thankfully did the txt -> rst conversion for can.txt) On 05/07/2018 11:35 AM, Mauro Carvalho Chehab wrote: > As stated at: > > http://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#footnotes > > A footnote should contain either a number, a reference or > an auto number, e. g.: > [1], [#f1] or [#]. > > While using [*] accidentaly works for html, it fails for other > document outputs. In particular, it causes an error with LaTeX > output, causing all books after networking to not be built. > > So, replace it by a valid syntax. > > Signed-off-by: Mauro Carvalho ChehabAcked-by: Oliver Hartkopp Thanks Mauro! Best regards, Oliver > --- > Documentation/networking/can.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/networking/can.rst > b/Documentation/networking/can.rst > index d23c51abf8c6..2fd0b51a8c52 100644 > --- a/Documentation/networking/can.rst > +++ b/Documentation/networking/can.rst > @@ -164,7 +164,7 @@ The Linux network devices (by default) just can handle the > transmission and reception of media dependent frames. Due to the > arbitration on the CAN bus the transmission of a low prio CAN-ID > may be delayed by the reception of a high prio CAN frame. To > -reflect the correct [*]_ traffic on the node the loopback of the sent > +reflect the correct [#f1]_ traffic on the node the loopback of the sent > data has to be performed right after a successful transmission. If > the CAN network interface is not capable of performing the loopback for > some reason the SocketCAN core can do this task as a fallback solution. > @@ -175,7 +175,7 @@ networking behaviour for CAN applications. Due to some > requests from > the RT-SocketCAN group the loopback optionally may be disabled for each > separate socket. See sockopts from the CAN RAW sockets in > :ref:`socketcan-raw-sockets`. > > -.. [*] you really like to have this when you're running analyser > +.. [#f1] you really like to have this when you're running analyser > tools like 'candump' or 'cansniffer' on the (same) node. > > > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 7/7] ocxl: Document new OCXL IOCTLs
Le 18/04/2018 à 03:08, Alastair D'Silva a écrit : From: Alastair D'SilvaSigned-off-by: Alastair D'Silva --- Acked-by: Frederic Barrat Fred Documentation/accelerators/ocxl.rst | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/accelerators/ocxl.rst b/Documentation/accelerators/ocxl.rst index 7904adcc07fd..3b8d3b99795c 100644 --- a/Documentation/accelerators/ocxl.rst +++ b/Documentation/accelerators/ocxl.rst @@ -157,6 +157,17 @@ OCXL_IOCTL_GET_METADATA: Obtains configuration information from the card, such at the size of MMIO areas, the AFU version, and the PASID for the current context. +OCXL_IOCTL_ENABLE_P9_WAIT: + + Allows the AFU to wake a userspace thread executing 'wait'. Returns + information to userspace to allow it to configure the AFU. Note that + this is only available on Power 9. + +OCXL_IOCTL_GET_FEATURES: + + Reports on which CPU features that affect OpenCAPI are usable from + userspace. + mmap -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/7] ocxl: Add an IOCTL so userspace knows what CPU features are available
Le 18/04/2018 à 03:08, Alastair D'Silva a écrit : From: Alastair D'SilvaIn order for a userspace AFU driver to call the Power9 specific OCXL_IOCTL_ENABLE_P9_WAIT, it needs to verify that it can actually make that call. Signed-off-by: Alastair D'Silva --- Documentation/accelerators/ocxl.rst | 1 - drivers/misc/ocxl/file.c| 25 + include/uapi/misc/ocxl.h| 4 3 files changed, 29 insertions(+), 1 deletion(-) diff --git a/Documentation/accelerators/ocxl.rst b/Documentation/accelerators/ocxl.rst index ddcc58d01cfb..7904adcc07fd 100644 --- a/Documentation/accelerators/ocxl.rst +++ b/Documentation/accelerators/ocxl.rst @@ -157,7 +157,6 @@ OCXL_IOCTL_GET_METADATA: Obtains configuration information from the card, such at the size of MMIO areas, the AFU version, and the PASID for the current context. - Intended? Other than that, Acked-by: Frederic Barrat mmap diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c index eb409a469f21..33ae46ce0a8a 100644 --- a/drivers/misc/ocxl/file.c +++ b/drivers/misc/ocxl/file.c @@ -168,12 +168,32 @@ static long afu_ioctl_enable_p9_wait(struct ocxl_context *ctx, } #endif + +static long afu_ioctl_get_features(struct ocxl_context *ctx, + struct ocxl_ioctl_features __user *uarg) +{ + struct ocxl_ioctl_features arg; + + memset(, 0, sizeof(arg)); + +#ifdef CONFIG_PPC64 + if (cpu_has_feature(CPU_FTR_P9_TIDR)) + arg.flags[0] |= OCXL_IOCTL_FEATURES_FLAGS0_P9_WAIT; +#endif + + if (copy_to_user(uarg, , sizeof(arg))) + return -EFAULT; + + return 0; +} + #define CMD_STR(x) (x == OCXL_IOCTL_ATTACH ? "ATTACH" : \ x == OCXL_IOCTL_IRQ_ALLOC ? "IRQ_ALLOC" : \ x == OCXL_IOCTL_IRQ_FREE ? "IRQ_FREE" : \ x == OCXL_IOCTL_IRQ_SET_FD ? "IRQ_SET_FD" : \ x == OCXL_IOCTL_GET_METADATA ? "GET_METADATA" : \ x == OCXL_IOCTL_ENABLE_P9_WAIT ? "ENABLE_P9_WAIT" : \ + x == OCXL_IOCTL_GET_FEATURES ? "GET_FEATURES" : \ "UNKNOWN") static long afu_ioctl(struct file *file, unsigned int cmd, @@ -239,6 +259,11 @@ static long afu_ioctl(struct file *file, unsigned int cmd, break; #endif + case OCXL_IOCTL_GET_FEATURES: + rc = afu_ioctl_get_features(ctx, + (struct ocxl_ioctl_features __user *) args); + break; + default: rc = -EINVAL; } diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h index 8d2748e69c84..bb80f294b429 100644 --- a/include/uapi/misc/ocxl.h +++ b/include/uapi/misc/ocxl.h @@ -55,6 +55,9 @@ struct ocxl_ioctl_p9_wait { __u64 reserved3[3]; }; +#define OCXL_IOCTL_FEATURES_FLAGS0_P9_WAIT 0x01 +struct ocxl_ioctl_features { + __u64 flags[4]; }; struct ocxl_ioctl_irq_fd { @@ -72,5 +75,6 @@ struct ocxl_ioctl_irq_fd { #define OCXL_IOCTL_IRQ_SET_FD _IOW(OCXL_MAGIC, 0x13, struct ocxl_ioctl_irq_fd) #define OCXL_IOCTL_GET_METADATA _IOR(OCXL_MAGIC, 0x14, struct ocxl_ioctl_metadata) #define OCXL_IOCTL_ENABLE_P9_WAIT _IOR(OCXL_MAGIC, 0x15, struct ocxl_ioctl_p9_wait) +#define OCXL_IOCTL_GET_FEATURES _IOR(OCXL_MAGIC, 0x16, struct ocxl_ioctl_platform) #endif /* _UAPI_MISC_OCXL_H */ -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/7] ocxl: Expose the thread_id needed for wait on p9
Le 18/04/2018 à 03:08, Alastair D'Silva a écrit : From: Alastair D'SilvaIn order to successfully issue as_notify, an AFU needs to know the TID to notify, which in turn means that this information should be available in userspace so it can be communicated to the AFU. Signed-off-by: Alastair D'Silva --- drivers/misc/ocxl/context.c | 5 +++- drivers/misc/ocxl/file.c | 53 +++ drivers/misc/ocxl/link.c | 36 ++ drivers/misc/ocxl/ocxl_internal.h | 1 + include/misc/ocxl.h | 9 +++ include/uapi/misc/ocxl.h | 10 6 files changed, 113 insertions(+), 1 deletion(-) diff --git a/drivers/misc/ocxl/context.c b/drivers/misc/ocxl/context.c index 909e8807824a..95f74623113e 100644 --- a/drivers/misc/ocxl/context.c +++ b/drivers/misc/ocxl/context.c @@ -34,6 +34,8 @@ int ocxl_context_init(struct ocxl_context *ctx, struct ocxl_afu *afu, mutex_init(>xsl_error_lock); mutex_init(>irq_lock); idr_init(>irq_idr); + ctx->tidr = 0; + /* * Keep a reference on the AFU to make sure it's valid for the * duration of the life of the context @@ -65,6 +67,7 @@ int ocxl_context_attach(struct ocxl_context *ctx, u64 amr) { int rc; + // Locks both status & tidr mutex_lock(>status_mutex); if (ctx->status != OPENED) { rc = -EIO; @@ -72,7 +75,7 @@ int ocxl_context_attach(struct ocxl_context *ctx, u64 amr) } rc = ocxl_link_add_pe(ctx->afu->fn->link, ctx->pasid, - current->mm->context.id, 0, amr, current->mm, + current->mm->context.id, ctx->tidr, amr, current->mm, xsl_fault_error, ctx); if (rc) goto out; diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c index 038509e5d031..eb409a469f21 100644 --- a/drivers/misc/ocxl/file.c +++ b/drivers/misc/ocxl/file.c @@ -5,6 +5,8 @@ #include #include #include +#include +#include #include "ocxl_internal.h" @@ -123,11 +125,55 @@ static long afu_ioctl_get_metadata(struct ocxl_context *ctx, return 0; } +#ifdef CONFIG_PPC64 +static long afu_ioctl_enable_p9_wait(struct ocxl_context *ctx, + struct ocxl_ioctl_p9_wait __user *uarg) +{ + struct ocxl_ioctl_p9_wait arg; + + memset(, 0, sizeof(arg)); + + if (cpu_has_feature(CPU_FTR_P9_TIDR)) { + enum ocxl_context_status status; + + // Locks both status & tidr + mutex_lock(>status_mutex); + if (!ctx->tidr) { + if (set_thread_tidr(current)) + return -ENOENT; + + ctx->tidr = current->thread.tidr; + } Now that we don't have the TIDR limit problem, I'm wondering if we cannot relax our rule a bit and have: - first thread to enable will become the default thread and update the Process element - any subsequent enable would just allocate the TIDR for the calling thread. That way, more than one thread could be used for 'wait'. Thoughts? Fred + + status = ctx->status; + mutex_unlock(>status_mutex); + + if (status == ATTACHED) { + int rc; + struct link *link = ctx->afu->fn->link; + + rc = ocxl_link_update_pe(link, ctx->pasid, ctx->tidr); + if (rc) + return rc; + } + + arg.thread_id = ctx->tidr; + } else + return -ENOENT; + + if (copy_to_user(uarg, , sizeof(arg))) + return -EFAULT; + + return 0; +} +#endif + #define CMD_STR(x) (x == OCXL_IOCTL_ATTACH ? "ATTACH" : \ x == OCXL_IOCTL_IRQ_ALLOC ? "IRQ_ALLOC" : \ x == OCXL_IOCTL_IRQ_FREE ? "IRQ_FREE" : \ x == OCXL_IOCTL_IRQ_SET_FD ? "IRQ_SET_FD" : \ x == OCXL_IOCTL_GET_METADATA ? "GET_METADATA" : \ + x == OCXL_IOCTL_ENABLE_P9_WAIT ? "ENABLE_P9_WAIT" : \ "UNKNOWN") static long afu_ioctl(struct file *file, unsigned int cmd, @@ -186,6 +232,13 @@ static long afu_ioctl(struct file *file, unsigned int cmd, (struct ocxl_ioctl_metadata __user *) args); break; +#ifdef CONFIG_PPC64 + case OCXL_IOCTL_ENABLE_P9_WAIT: + rc = afu_ioctl_enable_p9_wait(ctx, + (struct ocxl_ioctl_p9_wait __user *) args); + break; +#endif + default: rc = -EINVAL; } diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c index 656e8610eec2..88876ae8f330 100644 ---
Re: [PATCH v2 4/7] ocxl: Rename pnv_ocxl_spa_remove_pe to clarify it's action
Le 18/04/2018 à 03:08, Alastair D'Silva a écrit : From: Alastair D'SilvaThe function removes the process element from NPU cache. Signed-off-by: Alastair D'Silva --- Acked-by: Frederic Barrat arch/powerpc/include/asm/pnv-ocxl.h | 2 +- arch/powerpc/platforms/powernv/ocxl.c | 4 ++-- drivers/misc/ocxl/link.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/include/asm/pnv-ocxl.h b/arch/powerpc/include/asm/pnv-ocxl.h index f6945d3bc971..208b5503f4ed 100644 --- a/arch/powerpc/include/asm/pnv-ocxl.h +++ b/arch/powerpc/include/asm/pnv-ocxl.h @@ -28,7 +28,7 @@ extern int pnv_ocxl_map_xsl_regs(struct pci_dev *dev, void __iomem **dsisr, extern int pnv_ocxl_spa_setup(struct pci_dev *dev, void *spa_mem, int PE_mask, void **platform_data); extern void pnv_ocxl_spa_release(void *platform_data); -extern int pnv_ocxl_spa_remove_pe(void *platform_data, int pe_handle); +extern int pnv_ocxl_spa_remove_pe_from_cache(void *platform_data, int pe_handle); extern int pnv_ocxl_alloc_xive_irq(u32 *irq, u64 *trigger_addr); extern void pnv_ocxl_free_xive_irq(u32 irq); diff --git a/arch/powerpc/platforms/powernv/ocxl.c b/arch/powerpc/platforms/powernv/ocxl.c index fa9b53af3c7b..8c65aacda9c8 100644 --- a/arch/powerpc/platforms/powernv/ocxl.c +++ b/arch/powerpc/platforms/powernv/ocxl.c @@ -475,7 +475,7 @@ void pnv_ocxl_spa_release(void *platform_data) } EXPORT_SYMBOL_GPL(pnv_ocxl_spa_release); -int pnv_ocxl_spa_remove_pe(void *platform_data, int pe_handle) +int pnv_ocxl_spa_remove_pe_from_cache(void *platform_data, int pe_handle) { struct spa_data *data = (struct spa_data *) platform_data; int rc; @@ -483,7 +483,7 @@ int pnv_ocxl_spa_remove_pe(void *platform_data, int pe_handle) rc = opal_npu_spa_clear_cache(data->phb_opal_id, data->bdfn, pe_handle); return rc; } -EXPORT_SYMBOL_GPL(pnv_ocxl_spa_remove_pe); +EXPORT_SYMBOL_GPL(pnv_ocxl_spa_remove_pe_from_cache); int pnv_ocxl_alloc_xive_irq(u32 *irq, u64 *trigger_addr) { diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c index f30790582dc0..656e8610eec2 100644 --- a/drivers/misc/ocxl/link.c +++ b/drivers/misc/ocxl/link.c @@ -599,7 +599,7 @@ int ocxl_link_remove_pe(void *link_handle, int pasid) * On powerpc, the entry needs to be cleared from the context * cache of the NPU. */ - rc = pnv_ocxl_spa_remove_pe(link->platform_data, pe_handle); + rc = pnv_ocxl_spa_remove_pe_from_cache(link->platform_data, pe_handle); WARN_ON(rc); pe_data = radix_tree_delete(>pe_tree, pe_handle); -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/7] powerpc: use task_pid_nr() for TID allocation
Le 18/04/2018 à 03:08, Alastair D'Silva a écrit : From: Alastair D'SilvaThe current implementation of TID allocation, using a global IDR, may result in an errant process starving the system of available TIDs. Instead, use task_pid_nr(), as mentioned by the original author. The scenario described which prevented it's use is not applicable, as set_thread_tidr can only be called after the task struct has been populated. Here is how I understand what's going to happen if 2 threads are using the same TIDR value, which is possible with this patch (if unlikely): 1. waking up the wrong thread is not really a problem, as threads have to handle spurious wake up from the 'wait' instruction anyway, and must be using some other condition to know when to loop around the 'wait' instruction. 2. missing the right thread: if the wrong thread is on a CPU, and a wake_host_thread/as_notify is sent, the core will see a matching thread and will accept the command. The (open)capi adapter won't send an interrupt. The wrong thread is awaken, which is not a problem as discussed above. As the right thread to notify is not running, no harm is done either: as soon as the thread runs, it's supposed to check its condition (which will be met) or call 'wait', but 'wait' immediately returns when called the first time after a thread is scheduled. So I believe we are ok. But I think it requires a huge comment with the above (at the minimum) :-) With a comment: Reviewed-by: Frederic Barrat Fred Signed-off-by: Alastair D'Silva --- arch/powerpc/include/asm/switch_to.h | 1 - arch/powerpc/kernel/process.c| 97 +--- 2 files changed, 1 insertion(+), 97 deletions(-) diff --git a/arch/powerpc/include/asm/switch_to.h b/arch/powerpc/include/asm/switch_to.h index be8c9fa23983..5b03d8a82409 100644 --- a/arch/powerpc/include/asm/switch_to.h +++ b/arch/powerpc/include/asm/switch_to.h @@ -94,6 +94,5 @@ static inline void clear_task_ebb(struct task_struct *t) extern int set_thread_uses_vas(void); extern int set_thread_tidr(struct task_struct *t); -extern void clear_thread_tidr(struct task_struct *t); #endif /* _ASM_POWERPC_SWITCH_TO_H */ diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c index 3b00da47699b..87f047fd2762 100644 --- a/arch/powerpc/kernel/process.c +++ b/arch/powerpc/kernel/process.c @@ -1496,103 +1496,12 @@ int set_thread_uses_vas(void) } #ifdef CONFIG_PPC64 -static DEFINE_SPINLOCK(vas_thread_id_lock); -static DEFINE_IDA(vas_thread_ida); - -/* - * We need to assign a unique thread id to each thread in a process. - * - * This thread id, referred to as TIDR, and separate from the Linux's tgid, - * is intended to be used to direct an ASB_Notify from the hardware to the - * thread, when a suitable event occurs in the system. - * - * One such event is a "paste" instruction in the context of Fast Thread - * Wakeup (aka Core-to-core wake up in the Virtual Accelerator Switchboard - * (VAS) in POWER9. - * - * To get a unique TIDR per process we could simply reuse task_pid_nr() but - * the problem is that task_pid_nr() is not yet available copy_thread() is - * called. Fixing that would require changing more intrusive arch-neutral - * code in code path in copy_process()?. - * - * Further, to assign unique TIDRs within each process, we need an atomic - * field (or an IDR) in task_struct, which again intrudes into the arch- - * neutral code. So try to assign globally unique TIDRs for now. - * - * NOTE: TIDR 0 indicates that the thread does not need a TIDR value. - * For now, only threads that expect to be notified by the VAS - * hardware need a TIDR value and we assign values > 0 for those. - */ -#define MAX_THREAD_CONTEXT ((1 << 16) - 1) -static int assign_thread_tidr(void) -{ - int index; - int err; - unsigned long flags; - -again: - if (!ida_pre_get(_thread_ida, GFP_KERNEL)) - return -ENOMEM; - - spin_lock_irqsave(_thread_id_lock, flags); - err = ida_get_new_above(_thread_ida, 1, ); - spin_unlock_irqrestore(_thread_id_lock, flags); - - if (err == -EAGAIN) - goto again; - else if (err) - return err; - - if (index > MAX_THREAD_CONTEXT) { - spin_lock_irqsave(_thread_id_lock, flags); - ida_remove(_thread_ida, index); - spin_unlock_irqrestore(_thread_id_lock, flags); - return -ENOMEM; - } - - return index; -} - -static void free_thread_tidr(int id) -{ - unsigned long flags; - - spin_lock_irqsave(_thread_id_lock, flags); - ida_remove(_thread_ida, id); - spin_unlock_irqrestore(_thread_id_lock, flags); -} - -/* - * Clear any TIDR value assigned to this thread. - */ -void clear_thread_tidr(struct task_struct *t) -{ - if (!t->thread.tidr) -
Re: [PATCH v2 2/7] powerpc: Use TIDR CPU feature to control TIDR allocation
Le 18/04/2018 à 03:08, Alastair D'Silva a écrit : From: Alastair D'SilvaSwitch the use of TIDR on it's CPU feature, rather than assuming it is available based on architecture. Signed-off-by: Alastair D'Silva --- Reviewed-by: Frederic Barrat arch/powerpc/kernel/process.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c index 1237f13fed51..3b00da47699b 100644 --- a/arch/powerpc/kernel/process.c +++ b/arch/powerpc/kernel/process.c @@ -1154,7 +1154,7 @@ static inline void restore_sprs(struct thread_struct *old_thread, mtspr(SPRN_TAR, new_thread->tar); } - if (cpu_has_feature(CPU_FTR_ARCH_300) && + if (cpu_has_feature(CPU_FTR_P9_TIDR) && old_thread->tidr != new_thread->tidr) mtspr(SPRN_TIDR, new_thread->tidr); #endif @@ -1570,7 +1570,7 @@ void clear_thread_tidr(struct task_struct *t) if (!t->thread.tidr) return; - if (!cpu_has_feature(CPU_FTR_ARCH_300)) { + if (!cpu_has_feature(CPU_FTR_P9_TIDR)) { WARN_ON_ONCE(1); return; } @@ -1593,7 +1593,7 @@ int set_thread_tidr(struct task_struct *t) { int rc; - if (!cpu_has_feature(CPU_FTR_ARCH_300)) + if (!cpu_has_feature(CPU_FTR_P9_TIDR)) return -EINVAL; if (t != current) -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] powerpc: Add TIDR CPU feature for Power9
Le 18/04/2018 à 03:08, Alastair D'Silva a écrit : From: Alastair D'SilvaThis patch adds a CPU feature bit to show whether the CPU has the TIDR register available, enabling as_notify/wait in userspace. Signed-off-by: Alastair D'Silva --- arch/powerpc/include/asm/cputable.h | 3 ++- arch/powerpc/kernel/dt_cpu_ftrs.c | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h index 4e332f3531c5..54c4cbbe57b4 100644 --- a/arch/powerpc/include/asm/cputable.h +++ b/arch/powerpc/include/asm/cputable.h @@ -215,6 +215,7 @@ static inline void cpu_feature_keys_init(void) { } #define CPU_FTR_P9_TM_HV_ASSIST LONG_ASM_CONST(0x1000) #define CPU_FTR_P9_TM_XER_SO_BUG LONG_ASM_CONST(0x2000) #define CPU_FTR_P9_TLBIE_BUG LONG_ASM_CONST(0x4000) +#define CPU_FTR_P9_TIDR LONG_ASM_CONST(0x8000) #ifndef __ASSEMBLY__ @@ -462,7 +463,7 @@ static inline void cpu_feature_keys_init(void) { } CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY | \ CPU_FTR_DBELL | CPU_FTR_HAS_PPR | CPU_FTR_ARCH_207S | \ CPU_FTR_TM_COMP | CPU_FTR_ARCH_300 | CPU_FTR_PKEY | \ - CPU_FTR_P9_TLBIE_BUG) + CPU_FTR_P9_TLBIE_BUG | CPU_FTR_P9_TIDR) #define CPU_FTRS_POWER9_DD1 ((CPU_FTRS_POWER9 | CPU_FTR_POWER9_DD1) & \ (~CPU_FTR_SAO)) #define CPU_FTRS_POWER9_DD2_0 CPU_FTRS_POWER9 diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c b/arch/powerpc/kernel/dt_cpu_ftrs.c index 11a3a4fed3fb..10f8b7f55637 100644 --- a/arch/powerpc/kernel/dt_cpu_ftrs.c +++ b/arch/powerpc/kernel/dt_cpu_ftrs.c @@ -722,6 +722,7 @@ static __init void cpufeatures_cpu_quirks(void) if ((version & 0x) == 0x004e) { cur_cpu_spec->cpu_features &= ~(CPU_FTR_DAWR); cur_cpu_spec->cpu_features |= CPU_FTR_P9_TLBIE_BUG; > + cur_cpu_spec->cpu_features |= CPU_FTR_P9_TIDR; Isn't it redundant with adding the flag to CPU_FTRS_POWER9? Fred } } -- 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 15/18] iio: iio.h: use nested struct support on kernel-doc markup
On Mon, 7 May 2018 06:35:51 -0300 Mauro Carvalho Chehabwrote: > Solve those Sphinx warnings: > > ./include/linux/iio/iio.h:270: warning: Function parameter or member > 'scan_type.sign' not described in 'iio_chan_spec' > ./include/linux/iio/iio.h:270: warning: Function parameter or member > 'scan_type.realbits' not described in 'iio_chan_spec' > ./include/linux/iio/iio.h:270: warning: Function parameter or member > 'scan_type.storagebits' not described in 'iio_chan_spec' > ./include/linux/iio/iio.h:270: warning: Function parameter or member > 'scan_type.shift' not described in 'iio_chan_spec' > ./include/linux/iio/iio.h:270: warning: Function parameter or member > 'scan_type.repeat' not described in 'iio_chan_spec' > ./include/linux/iio/iio.h:270: warning: Function parameter or member > 'scan_type.endianness' not described in 'iio_chan_spec' > > ./include/linux/iio/iio.h:191: WARNING: Unexpected indentation. > ./include/linux/iio/iio.h:192: WARNING: Block quote ends without a blank > line; unexpected unindent. > ./include/linux/iio/iio.h:198: WARNING: Definition list ends without a > blank line; unexpected unindent. > > Signed-off-by: Mauro Carvalho Chehab Great thanks. I couldn't figure out how to do this last time I looked at it. Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to ignore it. Thanks, Jonathan > --- > include/linux/iio/iio.h | 24 > 1 file changed, 12 insertions(+), 12 deletions(-) > > diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h > index 11579fd4126e..a74cb177dc6f 100644 > --- a/include/linux/iio/iio.h > +++ b/include/linux/iio/iio.h > @@ -183,18 +183,18 @@ struct iio_event_spec { > * @address: Driver specific identifier. > * @scan_index: Monotonic index to give ordering in scans when > read > * from a buffer. > - * @scan_type: sign: 's' or 'u' to specify signed or > unsigned > - * realbits: Number of valid bits of data > - * storagebits:Realbits + padding > - * shift: Shift right by this before masking out > - * realbits. > - * repeat: Number of times real/storage bits > - * repeats. When the repeat element is > - * more than 1, then the type element in > - * sysfs will show a repeat value. > - * Otherwise, the number of repetitions is > - * omitted. > - * endianness: little or big endian > + * @scan_type: struct describing the scan type > + * @scan_type.sign: 's' or 'u' to specify signed or unsigned > + * @scan_type.realbits: Number of valid bits of data > + * @scan_type.storagebits: Realbits + padding > + * @scan_type.shift: Shift right by this before masking out > + * realbits. > + * @scan_type.repeat:Number of times real/storage bits > repeats. > + * When the repeat element is more than 1, then > + * the type element in sysfs will show a repeat > + * value. Otherwise, the number of repetitions > + * is omitted. > + * @scan_type.endianness:little or big endian > * @info_mask_separate: What information is to be exported that is specific > to > * this channel. > * @info_mask_separate_available: What availability information is to be -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/9] trace_uprobe: Support SDT markers having reference count (semaphore)
On Mon, 7 May 2018 13:51:21 +0530 Ravi Bangoriawrote: > Hi Masami, > > On 05/04/2018 07:51 PM, Ravi Bangoria wrote: > > > >>> +} > >>> + > >>> +static void sdt_increment_ref_ctr(struct trace_uprobe *tu) > >>> +{ > >>> + struct uprobe_map_info *info; > >>> + > >>> + uprobe_down_write_dup_mmap(); > >>> + info = uprobe_build_map_info(tu->inode->i_mapping, > >>> + tu->ref_ctr_offset, false); > >>> + if (IS_ERR(info)) > >>> + goto out; > >>> + > >>> + while (info) { > >>> + down_write(>mm->mmap_sem); > >>> + > >>> + if (sdt_find_vma(tu, info->mm, info->vaddr)) > >>> + sdt_update_ref_ctr(info->mm, info->vaddr, 1); > >> Don't you have to handle the error to map pages here? > > Correct.. I think, I've to feedback error code to > > probe_event_{enable|disable} > > and handler failure there. > > I looked at this. Actually, It looks difficult to feedback errors to > probe_event_{enable|disable}, esp. in the mmap() case. Hmm, can't you roll that back if sdt_increment_ref_ctr() fails? If so, how does sdt_decrement_ref_ctr() work in that case? > Is it fine if we just warn sdt_update_ref_ctr() failures in dmesg? I'm > doing this in [PATCH 7]. (Though, it makes more sense to do that in > [PATCH 6], will change it in next version). Of course we need to warn it at least, but the best is rejecting to enable it. > > Any better ideas? > > BTW, same issue exists for normal uprobe. If uprobe_mmap() fails, > there is no feedback to trace_uprobe and no warnigns in dmesg as > well !! There was a patch by Naveen to warn such failures in dmesg > but that didn't go in: https://lkml.org/lkml/2017/9/22/155 Oops, that's a real bug. It seems the ball is in Naveen's hand. Naveen, could you update it according to Oleg's comment, and resend it? > > Also, I'll add a check in sdt_update_ref_ctr() to make sure reference > counter never goes to negative incase increment fails but decrement > succeeds. OTOH, if increment succeeds but decrement fails, the > counter remains >0 but there is no harm as such, except we will > execute some unnecessary code. I see. Please carefully clarify whether such case is kernel's bug or not. I would like to know what the condition causes that uneven behavior. Thank you, > > Thanks, > Ravi > -- Masami Hiramatsu -- 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] libata: remove ata_sff_data_xfer_noirq()
On 2018-05-07 08:49:08 [-0700], Tejun Heo wrote: > Hello, Sebastian. > > On Fri, May 04, 2018 at 05:06:20PM +0200, Sebastian Andrzej Siewior wrote: > > ata_sff_data_xfer_noirq() is invoked via the ->sff_data_xfer hook. The > > latter is invoked by ata_pio_sector(), atapi_send_cdb() and > > __atapi_pio_bytes() which in turn is invoked by ata_sff_hsm_move(). > > The latter function requires that the "ap->lock" lock is held which > > needs to be taken with disabled interrupts. > > > > There is no need have to have ata_sff_data_xfer_noirq() which invokes > > ata_sff_data_xfer32() with disabled interrupts because at this point the > > interrupts are already disabled. > > Remove the function and its references to it and replace all callers > > with ata_sff_data_xfer32(). > > Can you please add irq disabled assert to ata_sff_data_xfer*()? Why irq-disabled assert? Can we use lockdep_assert_held() instead? > Thanks. Sebastian -- 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] libata: remove ata_sff_data_xfer_noirq()
Hello, Sebastian. On Fri, May 04, 2018 at 05:06:20PM +0200, Sebastian Andrzej Siewior wrote: > ata_sff_data_xfer_noirq() is invoked via the ->sff_data_xfer hook. The > latter is invoked by ata_pio_sector(), atapi_send_cdb() and > __atapi_pio_bytes() which in turn is invoked by ata_sff_hsm_move(). > The latter function requires that the "ap->lock" lock is held which > needs to be taken with disabled interrupts. > > There is no need have to have ata_sff_data_xfer_noirq() which invokes > ata_sff_data_xfer32() with disabled interrupts because at this point the > interrupts are already disabled. > Remove the function and its references to it and replace all callers > with ata_sff_data_xfer32(). Can you please add irq disabled assert to ata_sff_data_xfer*()? Thanks. -- tejun -- 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] certificate handling: Update references to the documentation
Commit 94e980cc45f2b2 ("Documentation/module-signing.txt: convert to ReST markup") converted the .txt doc. to ReST markup, but it did not update the references to the doc. (including in MAINTAINERS). Signed-off-by: Andrea Parri--- MAINTAINERS | 2 +- certs/Kconfig | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index df6e9bb2559af..803d4b4ff5f1d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3347,7 +3347,7 @@ M:David Howells M: David Woodhouse L: keyri...@vger.kernel.org S: Maintained -F: Documentation/module-signing.txt +F: Documentation/admin-guide/module-signing.rst F: certs/ F: scripts/sign-file.c F: scripts/extract-cert.c diff --git a/certs/Kconfig b/certs/Kconfig index 5f7663df6e8e3..c94e93d8bccf0 100644 --- a/certs/Kconfig +++ b/certs/Kconfig @@ -13,7 +13,7 @@ config MODULE_SIG_KEY If this option is unchanged from its default "certs/signing_key.pem", then the kernel will automatically generate the private key and - certificate as described in Documentation/module-signing.txt + certificate as described in Documentation/admin-guide/module-signing.rst config SYSTEM_TRUSTED_KEYRING bool "Provide system-wide ring of trusted keys" -- 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
Re: [PATCH 10/18] rcu: rcupdate.h: get rid of Sphinx warnings at rcu_pointer_handoff()
On Mon, May 07, 2018 at 06:35:46AM -0300, Mauro Carvalho Chehab wrote: > The code example at rcupdate.h currently produce lots of warnings: > > ./include/linux/rcupdate.h:572: WARNING: Unexpected indentation. > ./include/linux/rcupdate.h:576: WARNING: Unexpected indentation. > ./include/linux/rcupdate.h:580: WARNING: Block quote ends without a > blank line; unexpected unindent. > ./include/linux/rcupdate.h:582: WARNING: Block quote ends without a > blank line; unexpected unindent. > ./include/linux/rcupdate.h:582: WARNING: Inline literal start-string > without end-string. > > Change it to a code-block. > > Signed-off-by: Mauro Carvalho ChehabAcked-by: Paul E. McKenney If you don't tell me otherwise, I will assume that you are pushing this. If you would rather that I take it, please let me know! Thanx, Paul > --- > include/linux/rcupdate.h | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h > index 36360d07f25b..c890d10978fa 100644 > --- a/include/linux/rcupdate.h > +++ b/include/linux/rcupdate.h > @@ -568,8 +568,8 @@ static inline void rcu_preempt_sleep_check(void) { } > * This is simply an identity function, but it documents where a pointer > * is handed off from RCU to some other synchronization mechanism, for > * example, reference counting or locking. In C11, it would map to > - * kill_dependency(). It could be used as follows: > - * `` > + * kill_dependency(). It could be used as follows:: > + * > * rcu_read_lock(); > * p = rcu_dereference(gp); > * long_lived = is_long_lived(p); > @@ -580,7 +580,6 @@ static inline void rcu_preempt_sleep_check(void) { } > * p = rcu_pointer_handoff(p); > * } > * rcu_read_unlock(); > - *`` > */ > #define rcu_pointer_handoff(p) (p) > > -- > 2.17.0 > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/18] net: mac80211.h: fix a bad comment line
On Mon, 2018-05-07 at 15:37 +0300, Kalle Valo wrote: > Mauro Carvalho Chehabwrites: > > > Sphinx produces a lot of errors like this: > > ./include/net/mac80211.h:2083: warning: bad line: > > > > > Signed-off-by: Mauro Carvalho Chehab > > Randy already submitted a similar patch: > > https://patchwork.kernel.org/patch/10367275/ > > But it seems Johannes has not applied that yet. Yeah, I've been super busy preparing for the plugfest. I'll make a pass over all the patches as soon as I can, hopefully today or tomorrow. johannes -- 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 09/18] net: mac80211.h: fix a bad comment line
Mauro Carvalho Chehabwrites: > Sphinx produces a lot of errors like this: > ./include/net/mac80211.h:2083: warning: bad line: > > > Signed-off-by: Mauro Carvalho Chehab Randy already submitted a similar patch: https://patchwork.kernel.org/patch/10367275/ But it seems Johannes has not applied that yet. -- Kalle Valo -- 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 07/18] docs: core-api: add circular-buffers documentation
On Mon, May 07, 2018 at 06:35:43AM -0300, Mauro Carvalho Chehab wrote: > The circular-buffers.txt is already in ReST format. So, move it to the > core-api guide, where it belongs. > > Signed-off-by: Mauro Carvalho Chehab> --- > Documentation/00-INDEX | 2 -- > .../{circular-buffers.txt => core-api/circular-buffers.rst} | 0 > Documentation/core-api/index.rst| 1 + > Documentation/memory-barriers.txt | 2 +- > Documentation/translations/ko_KR/memory-barriers.txt| 2 +- > 5 files changed, 3 insertions(+), 4 deletions(-) > rename Documentation/{circular-buffers.txt => core-api/circular-buffers.rst} > (100%) Similarly: ./include/linux/circ_buf.h: * See Documentation/circular-buffers.txt for more information. ./drivers/lightnvm/pblk-rb.c: * (Documentation/circular-buffers.txt) ./drivers/media/dvb-core/dvb_ringbuffer.c: * for memory barriers also see Documentation/circular-buffers.txt Andrea > > diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX > index c6b81ef9827b..a9dd1384d8e3 100644 > --- a/Documentation/00-INDEX > +++ b/Documentation/00-INDEX > @@ -80,8 +80,6 @@ cdrom/ > - directory with information on the CD-ROM drivers that Linux has. > cgroup-v1/ > - cgroups v1 features, including cpusets and memory controller. > -circular-buffers.txt > - - how to make use of the existing circular buffer infrastructure > clk.txt > - info on the common clock framework > cma/ > diff --git a/Documentation/circular-buffers.txt > b/Documentation/core-api/circular-buffers.rst > similarity index 100% > rename from Documentation/circular-buffers.txt > rename to Documentation/core-api/circular-buffers.rst > diff --git a/Documentation/core-api/index.rst > b/Documentation/core-api/index.rst > index d4d71ee564ae..3864de589126 100644 > --- a/Documentation/core-api/index.rst > +++ b/Documentation/core-api/index.rst > @@ -26,6 +26,7 @@ Core utilities > genalloc > errseq > printk-formats > + circular-buffers > > Interfaces for kernel debugging > === > diff --git a/Documentation/memory-barriers.txt > b/Documentation/memory-barriers.txt > index 983249906fc6..33b8bc9573f8 100644 > --- a/Documentation/memory-barriers.txt > +++ b/Documentation/memory-barriers.txt > @@ -3083,7 +3083,7 @@ CIRCULAR BUFFERS > Memory barriers can be used to implement circular buffering without the need > of a lock to serialise the producer with the consumer. See: > > - Documentation/circular-buffers.txt > + Documentation/core-api/circular-buffers.rst > > for details. > > diff --git a/Documentation/translations/ko_KR/memory-barriers.txt > b/Documentation/translations/ko_KR/memory-barriers.txt > index 081937577c1a..2ec5fe0c9cf4 100644 > --- a/Documentation/translations/ko_KR/memory-barriers.txt > +++ b/Documentation/translations/ko_KR/memory-barriers.txt > @@ -3023,7 +3023,7 @@ smp_mb() 가 아니라 virt_mb() 를 사용해야 합니다. > 동기화에 락을 사용하지 않고 구현하는데에 사용될 수 있습니다. 더 자세한 내용을 > 위해선 다음을 참고하세요: > > - Documentation/circular-buffers.txt > + Documentation/core-api/circular-buffers.rst > > > = > -- > 2.17.0 > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/18] docs: core-api: add cachetlb documentation
On Mon, May 07, 2018 at 06:35:41AM -0300, Mauro Carvalho Chehab wrote: > The cachetlb.txt is already in ReST format. So, move it to the > core-api guide, where it belongs. > > Signed-off-by: Mauro Carvalho Chehab> --- > Documentation/00-INDEX| 2 -- > Documentation/{cachetlb.txt => core-api/cachetlb.rst} | 0 > Documentation/core-api/index.rst | 1 + > Documentation/memory-barriers.txt | 2 +- > Documentation/translations/ko_KR/memory-barriers.txt | 2 +- > 5 files changed, 3 insertions(+), 4 deletions(-) > rename Documentation/{cachetlb.txt => core-api/cachetlb.rst} (100%) I see a few "inline" references to the .txt file in -rc4 (see below): I am not sure if you managed to update them too. ./arch/microblaze/include/asm/cacheflush.h:/* Look at Documentation/cachetlb.txt */ ./arch/unicore32/include/asm/cacheflush.h: *See Documentation/cachetlb.txt for more information. ./arch/arm64/include/asm/cacheflush.h: *See Documentation/cachetlb.txt for more information. Please note that ./arch/arm/include/asm/cacheflush.h: * See Documentation/cachetlb.txt for more information. ./arch/xtensa/include/asm/cacheflush.h: * (see also Documentation/cachetlb.txt) ./arch/xtensa/include/asm/cacheflush.h:/* This is not required, see Documentation/cachetlb.txt */ Andrea > > diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX > index 53699c79ee54..04074059bcdc 100644 > --- a/Documentation/00-INDEX > +++ b/Documentation/00-INDEX > @@ -76,8 +76,6 @@ bus-devices/ > - directory with info on TI GPMC (General Purpose Memory Controller) > bus-virt-phys-mapping.txt > - how to access I/O mapped memory from within device drivers. > -cachetlb.txt > - - describes the cache/TLB flushing interfaces Linux uses. > cdrom/ > - directory with information on the CD-ROM drivers that Linux has. > cgroup-v1/ > diff --git a/Documentation/cachetlb.txt b/Documentation/core-api/cachetlb.rst > similarity index 100% > rename from Documentation/cachetlb.txt > rename to Documentation/core-api/cachetlb.rst > diff --git a/Documentation/core-api/index.rst > b/Documentation/core-api/index.rst > index c670a8031786..d4d71ee564ae 100644 > --- a/Documentation/core-api/index.rst > +++ b/Documentation/core-api/index.rst > @@ -14,6 +14,7 @@ Core utilities > kernel-api > assoc_array > atomic_ops > + cachetlb > refcount-vs-atomic > cpu_hotplug > idr > diff --git a/Documentation/memory-barriers.txt > b/Documentation/memory-barriers.txt > index 6dafc8085acc..983249906fc6 100644 > --- a/Documentation/memory-barriers.txt > +++ b/Documentation/memory-barriers.txt > @@ -2903,7 +2903,7 @@ is discarded from the CPU's cache and reloaded. To > deal with this, the > appropriate part of the kernel must invalidate the overlapping bits of the > cache on each CPU. > > -See Documentation/cachetlb.txt for more information on cache management. > +See Documentation/core-api/cachetlb.rst for more information on cache > management. > > > CACHE COHERENCY VS MMIO > diff --git a/Documentation/translations/ko_KR/memory-barriers.txt > b/Documentation/translations/ko_KR/memory-barriers.txt > index 0a0930ab4156..081937577c1a 100644 > --- a/Documentation/translations/ko_KR/memory-barriers.txt > +++ b/Documentation/translations/ko_KR/memory-barriers.txt > @@ -2846,7 +2846,7 @@ CPU 의 캐시에서 RAM 으로 쓰여지는 더티 캐시 라인에 의해 덮 > 문제를 해결하기 위해선, 커널의 적절한 부분에서 각 CPU 의 캐시 안의 문제가 되는 > 비트들을 무효화 시켜야 합니다. > > -캐시 관리에 대한 더 많은 정보를 위해선 Documentation/cachetlb.txt 를 > +캐시 관리에 대한 더 많은 정보를 위해선 Documentation/core-api/cachetlb.rst 를 > 참고하세요. > > > -- > 2.17.0 > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/18] mtd: rawnand.h: use nested union kernel-doc markups
Hi Boris, Em Mon, 7 May 2018 11:46:50 +0200 Boris Brezillonescreveu: > Hi Mauro, > > diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h > > index 5dad59b31244..b986f94906df 100644 > > --- a/include/linux/mtd/rawnand.h > > +++ b/include/linux/mtd/rawnand.h > > @@ -740,8 +740,9 @@ enum nand_data_interface_type { > > > > /** > > * struct nand_data_interface - NAND interface timing > > - * @type: type of the timing > > - * @timings: The timing, type according to @type > > + * @type: type of the timing > > + * @timings:The timing, type according to @type > > + * @timings.sdr: Use it when @type is %NAND_SDR_IFACE. > > Hm, really feels weird to do that. I mean, either we describe > timings.sdr or timings, but not both. I this case, I agree that > describing timings.sdr would make more sense than generically > describing any possible entries in the timings union. This struct is funny, as the union has just one item. I assume that the original intend is to be ready to have more timing types (or you had it in the past). By the time you have a second value there, describing the union would make more sense. > Is there a simple > way we can get rid of the warning we have when not describing timings > but all of its fields? There's no direct way. It won't be hard to add a way to do it, like applying the enclosed patch with ends by declaring timings as: * @timings: -- undescribed -- IMHO, this is uglier. The way I see is that, if the embed struct/union is not interesting enough to be described, the best would be to use an anonymous one like: struct nand_data_interface { enum nand_data_interface_type type; union { struct nand_sdr_timings sdr; }; }; With the above, kernel-doc will expect a description just for @sdr. Btw, if you want to see how nested struct/union is parsed, the scripts/kernel_doc logic is at dump_struct() function. When it finds an struct, it first handles private/public by simply removing everything that it is not public from the struct, by a very simple parser. Then, it converts nested struct/union into un-nested ones. E. g. it converts: struct { union { int foo1; }; union { int foo2; } bar; } foobar; into this internal representation: struct { int foo1; union; int bar.foo2; union bar; }; Then it runs the normal un-nested struct parser. Thanks, Mauro [PATCH] don't describe nested struct timings IMHO, this is an ugly hack, but it allows having nested structs (or fields) undescribed by purpose. Signed-off-by: Mauro Carvalho Chehab diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h index b986f94906df..b724c7edf532 100644 --- a/include/linux/mtd/rawnand.h +++ b/include/linux/mtd/rawnand.h @@ -741,7 +741,7 @@ enum nand_data_interface_type { /** * struct nand_data_interface - NAND interface timing * @type: type of the timing - * @timings:The timing, type according to @type + * @timings:-- undescribed -- * @timings.sdr: Use it when @type is %NAND_SDR_IFACE. */ struct nand_data_interface { diff --git a/scripts/kernel-doc b/scripts/kernel-doc index 0057d8eafcc1..196a2107c8c1 100755 --- a/scripts/kernel-doc +++ b/scripts/kernel-doc @@ -390,7 +390,7 @@ my $section = $section_default; my $section_context = "Context"; my $section_return = "Return"; -my $undescribed = "-- undescribed --"; +my $undescribed = "-- undescribed --\n"; reset_state(); -- 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
[RFC PATCH v3 1/6] Documentation/features: Add script that refreshes the arch support status files in place
Provides the script: Documentation/features/scripts/features-refresh.sh which operates on the arch-support.txt files and refreshes them in place. This way [1], "[...] we soft- decouple the refreshing of the entries from the introduction of the features, while still making it all easy to keep sync and to extend." [1] http://lkml.kernel.org/r/20180328122211.GA25420@andrea Suggested-by: Ingo MolnarSigned-off-by: Andrea Parri Cc: Ingo Molnar Cc: Jonathan Corbet Cc: Andrew Morton --- Documentation/features/scripts/features-refresh.sh | 98 ++ 1 file changed, 98 insertions(+) create mode 100755 Documentation/features/scripts/features-refresh.sh diff --git a/Documentation/features/scripts/features-refresh.sh b/Documentation/features/scripts/features-refresh.sh new file mode 100755 index 0..9e72d38a0720e --- /dev/null +++ b/Documentation/features/scripts/features-refresh.sh @@ -0,0 +1,98 @@ +# +# Small script that refreshes the kernel feature support status in place. +# + +for F_FILE in Documentation/features/*/*/arch-support.txt; do + F=$(grep "^# Kconfig:" "$F_FILE" | cut -c26-) + + # + # Each feature F is identified by a pair (O, K), where 'O' can + # be either the empty string (for 'nop') or "not" (the logical + # negation operator '!'); other operators are not supported. + # + O="" + K=$F + if [[ "$F" == !* ]]; then + O="not" + K=$(echo $F | sed -e 's/^!//g') + fi + + # + # F := (O, K) is 'valid' iff there is a Kconfig file (for some + # arch) which contains K. + # + # Notice that this definition entails an 'asymmetry' between + # the case 'O = ""' and the case 'O = "not"'. E.g., F may be + # _invalid_ if: + # + # [case 'O = ""'] + # 1) no arch provides support for F, + # 2) K does not exist (e.g., it was renamed/mis-typed); + # + # [case 'O = "not"'] + # 3) all archs provide support for F, + # 4) as in (2). + # + # The rationale for adopting this definition (and, thus, for + # keeping the asymmetry) is: + # + # We want to be able to 'detect' (2) (or (4)). + # + # (1) and (3) may further warn the developers about the fact + # that K can be removed. + # + F_VALID="false" + for ARCH_DIR in arch/*/; do + K_FILES=$(find $ARCH_DIR -name "Kconfig*") + K_GREP=$(grep "$K" $K_FILES) + if [ ! -z "$K_GREP" ]; then + F_VALID="true" + break + fi + done + if [ "$F_VALID" = "false" ]; then + printf "WARNING: '%s' is not a valid Kconfig\n" "$F" + fi + + T_FILE="$F_FILE.tmp" + grep "^#" $F_FILE > $T_FILE + echo "---" >> $T_FILE + echo "| arch |status|" >> $T_FILE + echo "---" >> $T_FILE + for ARCH_DIR in arch/*/; do + ARCH=$(echo $ARCH_DIR | sed -e 's/arch//g' | sed -e 's/\///g') + K_FILES=$(find $ARCH_DIR -name "Kconfig*") + K_GREP=$(grep "$K" $K_FILES) + # + # Arch support status values for (O, K) are updated according + # to the following rules. + # + # - ("", K) is 'supported by a given arch', if there is a + # Kconfig file for that arch which contains K; + # + # - ("not", K) is 'supported by a given arch', if there is + # no Kconfig file for that arch which contains K; + # + # - otherwise: preserve the previous status value (if any), + #default to 'not yet supported'. + # + # Notice that, according these rules, invalid features may be + # updated/modified. + # + if [ "$O" = "" ] && [ ! -z "$K_GREP" ]; then + printf "|%12s: | ok |\n" "$ARCH" >> $T_FILE + elif [ "$O" = "not" ] && [ -z "$K_GREP" ]; then + printf "|%12s: | ok |\n" "$ARCH" >> $T_FILE + else + S=$(grep -v "^#" "$F_FILE" | grep " $ARCH:") + if [ ! -z "$S" ]; then + echo "$S" >> $T_FILE + else + printf "|%12s: | TODO |\n" "$ARCH" \ + >> $T_FILE + fi + fi + done + echo "---" >> $T_FILE + mv $T_FILE $F_FILE +done -- 2.7.4 -- To unsubscribe from this list: send the line
[RFC PATCH v3 4/6] Documentation/features/locking: Use '!RWSEM_GENERIC_SPINLOCK' as Kconfig for 'rwsem-optimized'
Uses '!RWSEM_GENERIC_SPINLOCK' in place of 'Optimized asm/rwsem.h' as Kconfig for 'rwsem-optimized': the new Kconfig expresses this feature equivalently, while also enabling the script 'features-refresh.sh' to operate on the corresponding arch support status file. Also refreshes the status matrix by using the script 'features-refresh.sh'. Suggested-by: Ingo MolnarSigned-off-by: Andrea Parri Cc: Ingo Molnar Cc: Jonathan Corbet Cc: Andrew Morton --- Documentation/features/locking/rwsem-optimized/arch-support.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/features/locking/rwsem-optimized/arch-support.txt b/Documentation/features/locking/rwsem-optimized/arch-support.txt index 8afe24ffa3ab4..e54b1f1a8091d 100644 --- a/Documentation/features/locking/rwsem-optimized/arch-support.txt +++ b/Documentation/features/locking/rwsem-optimized/arch-support.txt @@ -1,6 +1,6 @@ # # Feature name: rwsem-optimized -# Kconfig: Optimized asm/rwsem.h +# Kconfig: !RWSEM_GENERIC_SPINLOCK # description: arch provides optimized rwsem APIs # --- @@ -8,8 +8,8 @@ --- | alpha: | ok | | arc: | TODO | -| arm: | TODO | -| arm64: | TODO | +| arm: | ok | +| arm64: | ok | | c6x: | TODO | | h8300: | TODO | | hexagon: | TODO | @@ -26,7 +26,7 @@ |s390: | ok | | sh: | ok | | sparc: | ok | -| um: | TODO | +| um: | ok | | unicore32: | TODO | | x86: | ok | | xtensa: | ok | -- 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
[RFC PATCH v3 2/6] Documentation/features: Refresh the arch support status files in place
Now that the script 'features-refresh.sh' is available, uses this script to refresh all the arch-support.txt files in place. Signed-off-by: Andrea ParriCc: Ingo Molnar Cc: Jonathan Corbet Cc: Andrew Morton --- Documentation/features/core/BPF-JIT/arch-support.txt | 2 ++ .../features/core/generic-idle-thread/arch-support.txt | 4 +++- Documentation/features/core/jump-labels/arch-support.txt | 2 ++ Documentation/features/core/tracehook/arch-support.txt | 2 ++ Documentation/features/debug/KASAN/arch-support.txt| 4 +++- Documentation/features/debug/gcov-profile-all/arch-support.txt | 2 ++ Documentation/features/debug/kgdb/arch-support.txt | 4 +++- .../features/debug/kprobes-on-ftrace/arch-support.txt | 2 ++ Documentation/features/debug/kprobes/arch-support.txt | 4 +++- Documentation/features/debug/kretprobes/arch-support.txt | 4 +++- Documentation/features/debug/optprobes/arch-support.txt| 4 +++- Documentation/features/debug/stackprotector/arch-support.txt | 2 ++ Documentation/features/debug/uprobes/arch-support.txt | 6 -- .../features/debug/user-ret-profiler/arch-support.txt | 2 ++ Documentation/features/io/dma-api-debug/arch-support.txt | 2 ++ Documentation/features/io/dma-contiguous/arch-support.txt | 4 +++- Documentation/features/io/sg-chain/arch-support.txt| 2 ++ Documentation/features/lib/strncasecmp/arch-support.txt| 2 ++ Documentation/features/locking/cmpxchg-local/arch-support.txt | 4 +++- Documentation/features/locking/lockdep/arch-support.txt| 4 +++- Documentation/features/locking/queued-rwlocks/arch-support.txt | 10 ++ .../features/locking/queued-spinlocks/arch-support.txt | 8 +--- .../features/locking/rwsem-optimized/arch-support.txt | 2 ++ Documentation/features/perf/kprobes-event/arch-support.txt | 6 -- Documentation/features/perf/perf-regs/arch-support.txt | 4 +++- Documentation/features/perf/perf-stackdump/arch-support.txt| 4 +++- .../features/sched/membarrier-sync-core/arch-support.txt | 2 ++ Documentation/features/sched/numa-balancing/arch-support.txt | 6 -- Documentation/features/seccomp/seccomp-filter/arch-support.txt | 6 -- .../features/time/arch-tick-broadcast/arch-support.txt | 4 +++- Documentation/features/time/clockevents/arch-support.txt | 4 +++- Documentation/features/time/context-tracking/arch-support.txt | 2 ++ Documentation/features/time/irq-time-acct/arch-support.txt | 4 +++- .../features/time/modern-timekeeping/arch-support.txt | 2 ++ Documentation/features/time/virt-cpuacct/arch-support.txt | 2 ++ Documentation/features/vm/ELF-ASLR/arch-support.txt| 4 +++- Documentation/features/vm/PG_uncached/arch-support.txt | 2 ++ Documentation/features/vm/THP/arch-support.txt | 2 ++ Documentation/features/vm/TLB/arch-support.txt | 2 ++ Documentation/features/vm/huge-vmap/arch-support.txt | 2 ++ Documentation/features/vm/ioremap_prot/arch-support.txt| 2 ++ Documentation/features/vm/numa-memblock/arch-support.txt | 4 +++- Documentation/features/vm/pte_special/arch-support.txt | 2 ++ 43 files changed, 117 insertions(+), 31 deletions(-) diff --git a/Documentation/features/core/BPF-JIT/arch-support.txt b/Documentation/features/core/BPF-JIT/arch-support.txt index 0b96b4e1e7d4a..d277f971ccd6b 100644 --- a/Documentation/features/core/BPF-JIT/arch-support.txt +++ b/Documentation/features/core/BPF-JIT/arch-support.txt @@ -17,10 +17,12 @@ |m68k: | TODO | | microblaze: | TODO | |mips: | ok | +| nds32: | TODO | | nios2: | TODO | |openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | +| riscv: | TODO | |s390: | ok | | sh: | TODO | | sparc: | ok | diff --git a/Documentation/features/core/generic-idle-thread/arch-support.txt b/Documentation/features/core/generic-idle-thread/arch-support.txt index 372a2b18a6172..0ef6acdb991c7 100644 --- a/Documentation/features/core/generic-idle-thread/arch-support.txt +++ b/Documentation/features/core/generic-idle-thread/arch-support.txt @@ -17,10 +17,12 @@ |m68k: | TODO | | microblaze: | TODO | |mips: | ok | +| nds32: | TODO | | nios2: | TODO | -|openrisc: | TODO | +|openrisc: | ok | | parisc: | ok | | powerpc: | ok | +| riscv: | ok | |s390: | ok | | sh: | ok | | sparc: | ok | diff --git a/Documentation/features/core/jump-labels/arch-support.txt
[RFC PATCH v3 3/6] Documentation/features/core: Add arch support status files for 'cBPF-JIT' and 'eBPF-JIT'
Commit 606b5908e split 'HAVE_BPF_JIT' into cBPF and eBPF variant. Adds arch support status files for the new variants, and removes the status file corresponding to 'HAVE_BPT_JIT'. The new status matrices were auto-generated using the script 'features-refresh.sh'. Signed-off-by: Andrea ParriCc: Ingo Molnar Cc: Jonathan Corbet Cc: Andrew Morton --- .../features/core/BPF-JIT/arch-support.txt | 33 -- .../features/core/cBPF-JIT/arch-support.txt| 33 ++ .../features/core/eBPF-JIT/arch-support.txt| 33 ++ 3 files changed, 66 insertions(+), 33 deletions(-) delete mode 100644 Documentation/features/core/BPF-JIT/arch-support.txt create mode 100644 Documentation/features/core/cBPF-JIT/arch-support.txt create mode 100644 Documentation/features/core/eBPF-JIT/arch-support.txt diff --git a/Documentation/features/core/BPF-JIT/arch-support.txt b/Documentation/features/core/BPF-JIT/arch-support.txt deleted file mode 100644 index d277f971ccd6b..0 --- a/Documentation/features/core/BPF-JIT/arch-support.txt +++ /dev/null @@ -1,33 +0,0 @@ -# -# Feature name: BPF-JIT -# Kconfig: HAVE_BPF_JIT -# description: arch supports BPF JIT optimizations -# ---- -| arch |status| ---- -| alpha: | TODO | -| arc: | TODO | -| arm: | ok | -| arm64: | ok | -| c6x: | TODO | -| h8300: | TODO | -| hexagon: | TODO | -|ia64: | TODO | -|m68k: | TODO | -| microblaze: | TODO | -|mips: | ok | -| nds32: | TODO | -| nios2: | TODO | -|openrisc: | TODO | -| parisc: | TODO | -| powerpc: | ok | -| riscv: | TODO | -|s390: | ok | -| sh: | TODO | -| sparc: | ok | -| um: | TODO | -| unicore32: | TODO | -| x86: | ok | -| xtensa: | TODO | ---- diff --git a/Documentation/features/core/cBPF-JIT/arch-support.txt b/Documentation/features/core/cBPF-JIT/arch-support.txt new file mode 100644 index 0..90459cdde3143 --- /dev/null +++ b/Documentation/features/core/cBPF-JIT/arch-support.txt @@ -0,0 +1,33 @@ +# +# Feature name: cBPF-JIT +# Kconfig: HAVE_CBPF_JIT +# description: arch supports cBPF JIT optimizations +# +--- +| arch |status| +--- +| alpha: | TODO | +| arc: | TODO | +| arm: | TODO | +| arm64: | TODO | +| c6x: | TODO | +| h8300: | TODO | +| hexagon: | TODO | +|ia64: | TODO | +|m68k: | TODO | +| microblaze: | TODO | +|mips: | ok | +| nds32: | TODO | +| nios2: | TODO | +|openrisc: | TODO | +| parisc: | TODO | +| powerpc: | ok | +| riscv: | TODO | +|s390: | TODO | +| sh: | TODO | +| sparc: | ok | +| um: | TODO | +| unicore32: | TODO | +| x86: | TODO | +| xtensa: | TODO | +--- diff --git a/Documentation/features/core/eBPF-JIT/arch-support.txt b/Documentation/features/core/eBPF-JIT/arch-support.txt new file mode 100644 index 0..c90a0382fe667 --- /dev/null +++ b/Documentation/features/core/eBPF-JIT/arch-support.txt @@ -0,0 +1,33 @@ +# +# Feature name: eBPF-JIT +# Kconfig: HAVE_EBPF_JIT +# description: arch supports eBPF JIT optimizations +# +--- +| arch |status| +--- +| alpha: | TODO | +| arc: | TODO | +| arm: | ok | +| arm64: | ok | +| c6x: | TODO | +| h8300: | TODO | +| hexagon: | TODO | +|ia64: | TODO | +|m68k: | TODO | +| microblaze: | TODO | +|mips: | ok | +| nds32: | TODO | +| nios2: | TODO | +|openrisc: | TODO | +| parisc: | TODO | +| powerpc: | ok | +| riscv: | TODO | +|s390: | ok | +| sh: | TODO | +| sparc: | ok | +| um: | TODO | +| unicore32: | TODO | +| x86: | ok | +| xtensa: | TODO | +--- -- 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
[RFC PATCH v3 5/6] Documentation/features/lib: Remove arch support status file for 'strncasecmp'
Suggested-by: Ingo MolnarSigned-off-by: Andrea Parri Cc: Ingo Molnar Cc: Jonathan Corbet Cc: Andrew Morton --- .../features/lib/strncasecmp/arch-support.txt | 33 -- 1 file changed, 33 deletions(-) delete mode 100644 Documentation/features/lib/strncasecmp/arch-support.txt diff --git a/Documentation/features/lib/strncasecmp/arch-support.txt b/Documentation/features/lib/strncasecmp/arch-support.txt deleted file mode 100644 index 6148f42c3d902..0 --- a/Documentation/features/lib/strncasecmp/arch-support.txt +++ /dev/null @@ -1,33 +0,0 @@ -# -# Feature name: strncasecmp -# Kconfig: __HAVE_ARCH_STRNCASECMP -# description: arch provides an optimized strncasecmp() function -# ---- -| arch |status| ---- -| alpha: | TODO | -| arc: | TODO | -| arm: | TODO | -| arm64: | TODO | -| c6x: | TODO | -| h8300: | TODO | -| hexagon: | TODO | -|ia64: | TODO | -|m68k: | TODO | -| microblaze: | TODO | -|mips: | TODO | -| nds32: | TODO | -| nios2: | TODO | -|openrisc: | TODO | -| parisc: | TODO | -| powerpc: | TODO | -| riscv: | TODO | -|s390: | TODO | -| sh: | TODO | -| sparc: | TODO | -| um: | TODO | -| unicore32: | TODO | -| x86: | TODO | -| xtensa: | TODO | ---- -- 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
[RFC PATCH v3 6/6] Documentation/features/vm: Remove arch support status file for 'pte_special'
Suggested-by: Ingo MolnarSigned-off-by: Andrea Parri Cc: Ingo Molnar Cc: Jonathan Corbet Cc: Andrew Morton --- .../features/vm/pte_special/arch-support.txt | 33 -- 1 file changed, 33 deletions(-) delete mode 100644 Documentation/features/vm/pte_special/arch-support.txt diff --git a/Documentation/features/vm/pte_special/arch-support.txt b/Documentation/features/vm/pte_special/arch-support.txt deleted file mode 100644 index 6a608a6dcf71d..0 --- a/Documentation/features/vm/pte_special/arch-support.txt +++ /dev/null @@ -1,33 +0,0 @@ -# -# Feature name: pte_special -# Kconfig: __HAVE_ARCH_PTE_SPECIAL -# description: arch supports the pte_special()/pte_mkspecial() VM APIs -# ---- -| arch |status| ---- -| alpha: | TODO | -| arc: | ok | -| arm: | ok | -| arm64: | ok | -| c6x: | TODO | -| h8300: | TODO | -| hexagon: | TODO | -|ia64: | TODO | -|m68k: | TODO | -| microblaze: | TODO | -|mips: | TODO | -| nds32: | TODO | -| nios2: | TODO | -|openrisc: | TODO | -| parisc: | TODO | -| powerpc: | ok | -| riscv: | TODO | -|s390: | ok | -| sh: | ok | -| sparc: | ok | -| um: | TODO | -| unicore32: | TODO | -| x86: | ok | -| xtensa: | TODO | ---- -- 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
[RFC PATCH v3 0/6] Documentation/features: Provide and apply 'features-refresh.sh'
Hi, This series provides the script 'features-refresh.sh', which operates on the arch support status files, and it applies this script to refresh the status files in place; previous discussions about this series are at [1]. The series is organized as follows. - Patch 1/6 adds the script to 'Documentation/features/scripts/'. - Patch 2/6 presents the results of running the script; this run also printed the messages WARNING: 'HAVE_BPF_JIT' is not a valid Kconfig WARNING: '__HAVE_ARCH_STRNCASECMP' is not a valid Kconfig WARNING: 'Optimized asm/rwsem.h' is not a valid Kconfig WARNING: '__HAVE_ARCH_PTE_SPECIAL' is not a valid Kconfig to standard output. - Patches 3-6/6 fix each of these warnings. (Applies on -rc4.) Cheers, Andrea [1] http://lkml.kernel.org/r/1523205027-31786-1-git-send-email-andrea.pa...@amarulasolutions.com http://lkml.kernel.org/r/1522774551-9503-1-git-send-email-andrea.pa...@amarulasolutions.com http://lkml.kernel.org/r/20180328122211.GA25420@andrea Changes in v3: - rebase on -rc4 Changes in v2: - support negation operators in Kconfig (suggested by Ingo Molnar) - reorder patches 2/6 and 3/6 (suggested by Ingo Molnar) - add patches 4-6/6 (suggested by Ingo Molnar) Andrea Parri (6): Documentation/features: Add script that refreshes the arch support status files in place Documentation/features: Refresh the arch support status files in place Documentation/features/core: Add arch support status files for 'cBPF-JIT' and 'eBPF-JIT' Documentation/features/locking: Use '!RWSEM_GENERIC_SPINLOCK' as Kconfig for 'rwsem-optimized' Documentation/features/lib: Remove arch support status file for 'strncasecmp' Documentation/features/vm: Remove arch support status file for 'pte_special' .../features/core/BPF-JIT/arch-support.txt | 31 --- .../features/core/cBPF-JIT/arch-support.txt| 33 .../features/core/eBPF-JIT/arch-support.txt| 33 .../core/generic-idle-thread/arch-support.txt | 4 +- .../features/core/jump-labels/arch-support.txt | 2 + .../features/core/tracehook/arch-support.txt | 2 + .../features/debug/KASAN/arch-support.txt | 4 +- .../debug/gcov-profile-all/arch-support.txt| 2 + Documentation/features/debug/kgdb/arch-support.txt | 4 +- .../debug/kprobes-on-ftrace/arch-support.txt | 2 + .../features/debug/kprobes/arch-support.txt| 4 +- .../features/debug/kretprobes/arch-support.txt | 4 +- .../features/debug/optprobes/arch-support.txt | 4 +- .../features/debug/stackprotector/arch-support.txt | 2 + .../features/debug/uprobes/arch-support.txt| 6 +- .../debug/user-ret-profiler/arch-support.txt | 2 + .../features/io/dma-api-debug/arch-support.txt | 2 + .../features/io/dma-contiguous/arch-support.txt| 4 +- .../features/io/sg-chain/arch-support.txt | 2 + .../features/lib/strncasecmp/arch-support.txt | 31 --- .../locking/cmpxchg-local/arch-support.txt | 4 +- .../features/locking/lockdep/arch-support.txt | 4 +- .../locking/queued-rwlocks/arch-support.txt| 10 ++- .../locking/queued-spinlocks/arch-support.txt | 8 +- .../locking/rwsem-optimized/arch-support.txt | 10 ++- .../features/perf/kprobes-event/arch-support.txt | 6 +- .../features/perf/perf-regs/arch-support.txt | 4 +- .../features/perf/perf-stackdump/arch-support.txt | 4 +- .../sched/membarrier-sync-core/arch-support.txt| 2 + .../features/sched/numa-balancing/arch-support.txt | 6 +- Documentation/features/scripts/features-refresh.sh | 98 ++ .../seccomp/seccomp-filter/arch-support.txt| 6 +- .../time/arch-tick-broadcast/arch-support.txt | 4 +- .../features/time/clockevents/arch-support.txt | 4 +- .../time/context-tracking/arch-support.txt | 2 + .../features/time/irq-time-acct/arch-support.txt | 4 +- .../time/modern-timekeeping/arch-support.txt | 2 + .../features/time/virt-cpuacct/arch-support.txt| 2 + .../features/vm/ELF-ASLR/arch-support.txt | 4 +- .../features/vm/PG_uncached/arch-support.txt | 2 + Documentation/features/vm/THP/arch-support.txt | 2 + Documentation/features/vm/TLB/arch-support.txt | 2 + .../features/vm/huge-vmap/arch-support.txt | 2 + .../features/vm/ioremap_prot/arch-support.txt | 2 + .../features/vm/numa-memblock/arch-support.txt | 4 +- .../features/vm/pte_special/arch-support.txt | 31 --- 46 files changed, 279 insertions(+), 128 deletions(-) delete mode 100644 Documentation/features/core/BPF-JIT/arch-support.txt create mode 100644 Documentation/features/core/cBPF-JIT/arch-support.txt create mode 100644 Documentation/features/core/eBPF-JIT/arch-support.txt delete mode 100644 Documentation/features/lib/strncasecmp/arch-support.txt create mode 100755
Re: [PATCH 16/18] mtd: rawnand.h: use nested union kernel-doc markups
Hi Mauro, On Mon, 7 May 2018 06:35:52 -0300 Mauro Carvalho Chehabwrote: > Gets rid of those warnings and better document the parameters. > > ./include/linux/mtd/rawnand.h:752: warning: Function parameter or member > 'timings.sdr' not described in 'nand_data_interface' > ./include/linux/mtd/rawnand.h:817: warning: Function parameter or member > 'buf' not described in 'nand_op_data_instr' > ./include/linux/mtd/rawnand.h:817: warning: Function parameter or member > 'buf.in' not described in 'nand_op_data_instr' > ./include/linux/mtd/rawnand.h:817: warning: Function parameter or member > 'buf.out' not described in 'nand_op_data_instr' > ./include/linux/mtd/rawnand.h:863: warning: Function parameter or member > 'ctx' not described in 'nand_op_instr' > ./include/linux/mtd/rawnand.h:863: warning: Function parameter or member > 'ctx.cmd' not described in 'nand_op_instr' > ./include/linux/mtd/rawnand.h:863: warning: Function parameter or member > 'ctx.addr' not described in 'nand_op_instr' > ./include/linux/mtd/rawnand.h:863: warning: Function parameter or member > 'ctx.data' not described in 'nand_op_instr' > ./include/linux/mtd/rawnand.h:863: warning: Function parameter or member > 'ctx.waitrdy' not described in 'nand_op_instr' > ./include/linux/mtd/rawnand.h:1010: warning: Function parameter or member > 'ctx' not described in 'nand_op_parser_pattern_elem' > ./include/linux/mtd/rawnand.h:1010: warning: Function parameter or member > 'ctx.addr' not described in 'nand_op_parser_pattern_elem' > ./include/linux/mtd/rawnand.h:1010: warning: Function parameter or member > 'ctx.data' not described in 'nand_op_parser_pattern_elem' > ./include/linux/mtd/rawnand.h:1313: warning: Function parameter or member > 'manufacturer.desc' not described in 'nand_chip' > ./include/linux/mtd/rawnand.h:1313: warning: Function parameter or member > 'manufacturer.priv' not described in 'nand_chip' > > ./include/linux/mtd/rawnand.h:848: WARNING: Unexpected indentation. > > Signed-off-by: Mauro Carvalho Chehab > --- > include/linux/mtd/rawnand.h | 26 ++ > 1 file changed, 18 insertions(+), 8 deletions(-) > > diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h > index 5dad59b31244..b986f94906df 100644 > --- a/include/linux/mtd/rawnand.h > +++ b/include/linux/mtd/rawnand.h > @@ -740,8 +740,9 @@ enum nand_data_interface_type { > > /** > * struct nand_data_interface - NAND interface timing > - * @type:type of the timing > - * @timings: The timing, type according to @type > + * @type: type of the timing > + * @timings: The timing, type according to @type > + * @timings.sdr: Use it when @type is %NAND_SDR_IFACE. Hm, really feels weird to do that. I mean, either we describe timings.sdr or timings, but not both. I this case, I agree that describing timings.sdr would make more sense than generically describing any possible entries in the timings union. Is there a simple way we can get rid of the warning we have when not describing timings but all of its fields? > */ > struct nand_data_interface { > enum nand_data_interface_type type; > @@ -798,8 +799,9 @@ struct nand_op_addr_instr { > /** > * struct nand_op_data_instr - Definition of a data instruction > * @len: number of data bytes to move > - * @in: buffer to fill when reading from the NAND chip > - * @out: buffer to read from when writing to the NAND chip > + * @buf: buffer to fill > + * @buf.in: buffer to fill when reading from the NAND chip > + * @buf.out: buffer to read from when writing to the NAND chip Same here. What we care about is @buf.in and @buf.out, the @buf description is useless... Regards, Boris -- 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 04/18] docs: admin-guide: add bcache documentation
The bcache.txt is already in ReST format. So, move it to the admin guide, where it belongs. Signed-off-by: Mauro Carvalho Chehab--- Documentation/00-INDEX | 2 -- Documentation/{bcache.txt => admin-guide/bcache.rst} | 0 Documentation/admin-guide/index.rst | 1 + 3 files changed, 1 insertion(+), 2 deletions(-) rename Documentation/{bcache.txt => admin-guide/bcache.rst} (100%) diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 708dc4c166e4..53699c79ee54 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -64,8 +64,6 @@ auxdisplay/ - misc. LCD driver documentation (cfag12864b, ks0108). backlight/ - directory with info on controlling backlights in flat panel displays -bcache.txt - - Block-layer cache on fast SSDs to improve slow (raid) I/O performance. block/ - info on the Block I/O (BIO) layer. blockdev/ diff --git a/Documentation/bcache.txt b/Documentation/admin-guide/bcache.rst similarity index 100% rename from Documentation/bcache.txt rename to Documentation/admin-guide/bcache.rst diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst index cac906fb0ed0..52eb3408f9a0 100644 --- a/Documentation/admin-guide/index.rst +++ b/Documentation/admin-guide/index.rst @@ -60,6 +60,7 @@ configure specific aspects of kernel behavior to your liking. mono java ras + bcache pm/index thunderbolt LSM/index -- 2.17.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/18] docs: core-api: add cgroup-v2 documentation
The cgroup-v2.txt is already in ReST format. So, move it to the core-api guide, where it belongs. Signed-off-by: Mauro Carvalho Chehab--- Documentation/00-INDEX | 2 -- Documentation/{cgroup-v2.txt => admin-guide/cgroup-v2.rst} | 0 Documentation/admin-guide/index.rst| 1 + 3 files changed, 1 insertion(+), 2 deletions(-) rename Documentation/{cgroup-v2.txt => admin-guide/cgroup-v2.rst} (100%) diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 04074059bcdc..c6b81ef9827b 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -80,8 +80,6 @@ cdrom/ - directory with information on the CD-ROM drivers that Linux has. cgroup-v1/ - cgroups v1 features, including cpusets and memory controller. -cgroup-v2.txt - - cgroups v2 features, including cpusets and memory controller. circular-buffers.txt - how to make use of the existing circular buffer infrastructure clk.txt diff --git a/Documentation/cgroup-v2.txt b/Documentation/admin-guide/cgroup-v2.rst similarity index 100% rename from Documentation/cgroup-v2.txt rename to Documentation/admin-guide/cgroup-v2.rst diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst index 52eb3408f9a0..48d70af11652 100644 --- a/Documentation/admin-guide/index.rst +++ b/Documentation/admin-guide/index.rst @@ -48,6 +48,7 @@ configure specific aspects of kernel behavior to your liking. :maxdepth: 1 initrd + cgroup-v2 serial-console braille-console parport -- 2.17.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/18] docs: driver-api: add clk documentation
The clk.rst is already in ReST format. So, move it to the driver-api guide, where it belongs. Signed-off-by: Mauro Carvalho Chehab--- Documentation/00-INDEX | 2 -- Documentation/admin-guide/kernel-parameters.txt | 2 +- Documentation/{clk.txt => driver-api/clk.rst} | 0 Documentation/driver-api/index.rst | 1 + 4 files changed, 2 insertions(+), 3 deletions(-) rename Documentation/{clk.txt => driver-api/clk.rst} (100%) diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index a9dd1384d8e3..2754fe83f0d4 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -80,8 +80,6 @@ cdrom/ - directory with information on the CD-ROM drivers that Linux has. cgroup-v1/ - cgroups v1 features, including cpusets and memory controller. -clk.txt - - info on the common clock framework cma/ - Continuous Memory Area (CMA) debugfs interface. conf.py diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 865a24e4d516..42f3e2884e7c 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -518,7 +518,7 @@ those clocks in any way. This parameter is useful for debug and development, but should not be needed on a platform with proper driver support. For more - information, see Documentation/clk.txt. + information, see Documentation/driver-api/clk.rst. clock= [BUGS=X86-32, HW] gettimeofday clocksource override. [Deprecated] diff --git a/Documentation/clk.txt b/Documentation/driver-api/clk.rst similarity index 100% rename from Documentation/clk.txt rename to Documentation/driver-api/clk.rst diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index 3ac51c94f97b..5d04296f5ce0 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -17,6 +17,7 @@ available subsections can be seen below. basics infrastructure pm/index + clk device-io device_connection dma-buf -- 2.17.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/18] time: timer.c: adjust a kernel-doc comment
Those three warnings can easily solved by using :: to indicate a code block: ./kernel/time/timer.c:1259: WARNING: Unexpected indentation. ./kernel/time/timer.c:1261: WARNING: Unexpected indentation. ./kernel/time/timer.c:1262: WARNING: Block quote ends without a blank line; unexpected unindent. While here, align the lines at the block. Signed-off-by: Mauro Carvalho Chehab--- kernel/time/timer.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/kernel/time/timer.c b/kernel/time/timer.c index 4a4fd567fb26..cc2d23e6ff61 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -1251,18 +1251,18 @@ EXPORT_SYMBOL(try_to_del_timer_sync); * * Note: For !irqsafe timers, you must not hold locks that are held in * interrupt context while calling this function. Even if the lock has - * nothing to do with the timer in question. Here's why: + * nothing to do with the timer in question. Here's why:: * *CPU0 CPU1 * - * - * call_timer_fn(); - * base->running_timer = mytimer; - * spin_lock_irq(somelock); + * + * call_timer_fn(); + * base->running_timer = mytimer; + *spin_lock_irq(somelock); * *spin_lock(somelock); - * del_timer_sync(mytimer); - * while (base->running_timer == mytimer); + *del_timer_sync(mytimer); + *while (base->running_timer == mytimer); * * Now del_timer_sync() will never return and never release somelock. * The interrupt on the other CPU is waiting to grab somelock but -- 2.17.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/18] docs: */index.rst: Add newer documents to their respective index.rst
A number of new docs were added, but they're currently not on the index.rst from the session they're supposed to be, causing Sphinx warnings. Add them. Signed-off-by: Mauro Carvalho Chehab--- Documentation/crypto/index.rst | 1 + Documentation/driver-api/index.rst | 1 + Documentation/process/index.rst| 1 + Documentation/security/index.rst | 2 ++ 4 files changed, 5 insertions(+) diff --git a/Documentation/crypto/index.rst b/Documentation/crypto/index.rst index 94c4786f2573..c4ff5d791233 100644 --- a/Documentation/crypto/index.rst +++ b/Documentation/crypto/index.rst @@ -20,5 +20,6 @@ for cryptographic use cases, as well as programming examples. architecture devel-algos userspace-if + crypto_engine api api-samples diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index 6d8352c0f354..3ac51c94f97b 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -18,6 +18,7 @@ available subsections can be seen below. infrastructure pm/index device-io + device_connection dma-buf device_link message-based diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst index 1c9fe657ed01..37bd0628b6ee 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -52,6 +52,7 @@ lack of a better place. adding-syscalls magic-number volatile-considered-harmful + clang-format .. only:: subproject and html diff --git a/Documentation/security/index.rst b/Documentation/security/index.rst index 298a94a33f05..85492bfca530 100644 --- a/Documentation/security/index.rst +++ b/Documentation/security/index.rst @@ -9,5 +9,7 @@ Security Documentation IMA-templates keys/index LSM + LSM-sctp + SELinux-sctp self-protection tpm/index -- 2.17.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/18] docs: core-api: add cachetlb documentation
The cachetlb.txt is already in ReST format. So, move it to the core-api guide, where it belongs. Signed-off-by: Mauro Carvalho Chehab--- Documentation/00-INDEX| 2 -- Documentation/{cachetlb.txt => core-api/cachetlb.rst} | 0 Documentation/core-api/index.rst | 1 + Documentation/memory-barriers.txt | 2 +- Documentation/translations/ko_KR/memory-barriers.txt | 2 +- 5 files changed, 3 insertions(+), 4 deletions(-) rename Documentation/{cachetlb.txt => core-api/cachetlb.rst} (100%) diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 53699c79ee54..04074059bcdc 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -76,8 +76,6 @@ bus-devices/ - directory with info on TI GPMC (General Purpose Memory Controller) bus-virt-phys-mapping.txt - how to access I/O mapped memory from within device drivers. -cachetlb.txt - - describes the cache/TLB flushing interfaces Linux uses. cdrom/ - directory with information on the CD-ROM drivers that Linux has. cgroup-v1/ diff --git a/Documentation/cachetlb.txt b/Documentation/core-api/cachetlb.rst similarity index 100% rename from Documentation/cachetlb.txt rename to Documentation/core-api/cachetlb.rst diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index c670a8031786..d4d71ee564ae 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -14,6 +14,7 @@ Core utilities kernel-api assoc_array atomic_ops + cachetlb refcount-vs-atomic cpu_hotplug idr diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 6dafc8085acc..983249906fc6 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -2903,7 +2903,7 @@ is discarded from the CPU's cache and reloaded. To deal with this, the appropriate part of the kernel must invalidate the overlapping bits of the cache on each CPU. -See Documentation/cachetlb.txt for more information on cache management. +See Documentation/core-api/cachetlb.rst for more information on cache management. CACHE COHERENCY VS MMIO diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt index 0a0930ab4156..081937577c1a 100644 --- a/Documentation/translations/ko_KR/memory-barriers.txt +++ b/Documentation/translations/ko_KR/memory-barriers.txt @@ -2846,7 +2846,7 @@ CPU 의 캐시에서 RAM 으로 쓰여지는 더티 캐시 라인에 의해 덮 문제를 해결하기 위해선, 커널의 적절한 부분에서 각 CPU 의 캐시 안의 문제가 되는 비트들을 무효화 시켜야 합니다. -캐시 관리에 대한 더 많은 정보를 위해선 Documentation/cachetlb.txt 를 +캐시 관리에 대한 더 많은 정보를 위해선 Documentation/core-api/cachetlb.rst 를 참고하세요. -- 2.17.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/18] docs: fix location of request_firmware & friends
commit 5d6d1ddd2730 ("firmware: move firmware loader into its own directory") and other commits renamed the old firmware_class.c file and split it into separate files, but documentation was not changed accordingly, causing Sphinx errors. Change the location accordingly at the documentation files. While here, add a missing entry at request_firmware.rst for release_firmware() function. Fixes: 5d6d1ddd2730 ("firmware: move firmware loader into its own directory") Cc: Kees CookCc: Luis R. Rodriguez Cc: Greg Kroah-Hartman Signed-off-by: Mauro Carvalho Chehab --- Documentation/dell_rbu.txt | 4 ++-- .../driver-api/firmware/fallback-mechanisms.rst | 2 +- .../driver-api/firmware/request_firmware.rst| 17 +++-- Documentation/driver-api/infrastructure.rst | 2 +- Documentation/power/suspend-and-cpuhotplug.txt | 2 +- 5 files changed, 16 insertions(+), 11 deletions(-) diff --git a/Documentation/dell_rbu.txt b/Documentation/dell_rbu.txt index 0fdb6aa2704c..befeff80e7ec 100644 --- a/Documentation/dell_rbu.txt +++ b/Documentation/dell_rbu.txt @@ -121,8 +121,8 @@ read back the image downloaded. .. note:: - This driver requires a patch for firmware_class.c which has the modified - request_firmware_nowait function. + This driver requires a patch for drivers/base/firmware_loader/main.c + which has the modified request_firmware_nowait() function. Also after updating the BIOS image a user mode application needs to execute code which sends the BIOS update request to the BIOS. So on the next reboot diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst b/Documentation/driver-api/firmware/fallback-mechanisms.rst index f353783ae0be..7aed31b5a439 100644 --- a/Documentation/driver-api/firmware/fallback-mechanisms.rst +++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst @@ -72,7 +72,7 @@ the firmware requested, and establishes it in the device hierarchy by associating the device used to make the request as the device's parent. The sysfs directory's file attributes are defined and controlled through the new device's class (firmware_class) and group (fw_dev_attr_groups). -This is actually where the original firmware_class.c file name comes from, +This is actually where drivers/base/firmware_loader/fallback.c comes from, as originally the only firmware loading mechanism available was the mechanism we now use as a fallback mechanism. diff --git a/Documentation/driver-api/firmware/request_firmware.rst b/Documentation/driver-api/firmware/request_firmware.rst index cf4516dfbf96..8e34d29ea02d 100644 --- a/Documentation/driver-api/firmware/request_firmware.rst +++ b/Documentation/driver-api/firmware/request_firmware.rst @@ -17,19 +17,24 @@ an error is returned. request_firmware -.. kernel-doc:: drivers/base/firmware_class.c +.. kernel-doc:: drivers/base/firmware_loader/main.c :functions: request_firmware request_firmware_direct --- -.. kernel-doc:: drivers/base/firmware_class.c +.. kernel-doc:: drivers/base/firmware_loader/main.c :functions: request_firmware_direct request_firmware_into_buf - -.. kernel-doc:: drivers/base/firmware_class.c +.. kernel-doc:: drivers/base/firmware_loader/main.c :functions: request_firmware_into_buf +release_firmware + +.. kernel-doc:: drivers/base/firmware_loader/main.c + :functions: release_firmware + Asynchronous firmware requests == @@ -41,7 +46,7 @@ in atomic contexts. request_firmware_nowait --- -.. kernel-doc:: drivers/base/firmware_class.c +.. kernel-doc:: drivers/base/firmware_loader/main.c :functions: request_firmware_nowait Special optimizations on reboot @@ -54,8 +59,8 @@ this can be done with firmware_request_cache() insted of requesting for the firmare to be loaded. firmware_request_cache() -.. kernel-doc:: drivers/base/firmware_class.c + +.. kernel-doc:: drivers/base/firmware_loader/main.c :functions: firmware_request_cache request firmware API expected driver use diff --git a/Documentation/driver-api/infrastructure.rst b/Documentation/driver-api/infrastructure.rst index 6d9ff316b608..bee1b9a1702f 100644 --- a/Documentation/driver-api/infrastructure.rst +++ b/Documentation/driver-api/infrastructure.rst @@ -28,7 +28,7 @@ Device Drivers Base .. kernel-doc:: drivers/base/node.c :internal: -.. kernel-doc:: drivers/base/firmware_class.c +.. kernel-doc:: drivers/base/firmware_loader/main.c :export: .. kernel-doc:: drivers/base/transport_class.c diff --git a/Documentation/power/suspend-and-cpuhotplug.txt b/Documentation/power/suspend-and-cpuhotplug.txt index 31abd04b9572..6f55eb960a6d 100644 --- a/Documentation/power/suspend-and-cpuhotplug.txt +++
[PATCH 14/18] fbdev: modedb.c: fix a kernel-doc markup
Use code blocks to avoid those warnings and make it look nicer. ./drivers/video/fbdev/core/modedb.c:647: WARNING: Inline strong start-string without end-string. ./drivers/video/fbdev/core/modedb.c:647: WARNING: Inline strong start-string without end-string. ./drivers/video/fbdev/core/modedb.c:647: WARNING: Inline strong start-string without end-string. ./drivers/video/fbdev/core/modedb.c:647: WARNING: Inline strong start-string without end-string. Signed-off-by: Mauro Carvalho Chehab--- drivers/video/fbdev/core/modedb.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/video/fbdev/core/modedb.c b/drivers/video/fbdev/core/modedb.c index 2510fa728d77..7284324fbd77 100644 --- a/drivers/video/fbdev/core/modedb.c +++ b/drivers/video/fbdev/core/modedb.c @@ -642,23 +642,23 @@ static int fb_try_mode(struct fb_var_screeninfo *var, struct fb_info *info, * @default_mode fails, all modes in the video mode database will * be tried. * - * Valid mode specifiers for @mode_option: + * Valid mode specifiers for @mode_option:: * - * x[M][R][-][@][i][m] or - * [-][@] + * x[M][R][-][@][i][m] or + * [-][@] * * with , , and decimal numbers and * a string. * - * If 'M' is present after yres (and before refresh/bpp if present), - * the function will compute the timings using VESA(tm) Coordinated - * Video Timings (CVT). If 'R' is present after 'M', will compute with - * reduced blanking (for flatpanels). If 'i' is present, compute - * interlaced mode. If 'm' is present, add margins equal to 1.8% - * of xres rounded down to 8 pixels, and 1.8% of yres. The char - * 'i' and 'm' must be after 'M' and 'R'. Example: + * If 'M' is present after yres (and before refresh/bpp if present), + * the function will compute the timings using VESA(tm) Coordinated + * Video Timings (CVT). If 'R' is present after 'M', will compute with + * reduced blanking (for flatpanels). If 'i' is present, compute + * interlaced mode. If 'm' is present, add margins equal to 1.8% + * of xres rounded down to 8 pixels, and 1.8% of yres. The char + * 'i' and 'm' must be after 'M' and 'R'. Example:: * - * 1024x768MR-8@60m - Reduced blank with margins at 60Hz. + * 1024x768MR-8@60m - Reduced blank with margins at 60Hz. * * NOTE: The passed struct @var is _not_ cleared! This allows you * to supply values for e.g. the grayscale and accel_flags fields. -- 2.17.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/18] docs: can.rst: fix a footnote reference
As stated at: http://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#footnotes A footnote should contain either a number, a reference or an auto number, e. g.: [1], [#f1] or [#]. While using [*] accidentaly works for html, it fails for other document outputs. In particular, it causes an error with LaTeX output, causing all books after networking to not be built. So, replace it by a valid syntax. Signed-off-by: Mauro Carvalho Chehab--- Documentation/networking/can.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/networking/can.rst b/Documentation/networking/can.rst index d23c51abf8c6..2fd0b51a8c52 100644 --- a/Documentation/networking/can.rst +++ b/Documentation/networking/can.rst @@ -164,7 +164,7 @@ The Linux network devices (by default) just can handle the transmission and reception of media dependent frames. Due to the arbitration on the CAN bus the transmission of a low prio CAN-ID may be delayed by the reception of a high prio CAN frame. To -reflect the correct [*]_ traffic on the node the loopback of the sent +reflect the correct [#f1]_ traffic on the node the loopback of the sent data has to be performed right after a successful transmission. If the CAN network interface is not capable of performing the loopback for some reason the SocketCAN core can do this task as a fallback solution. @@ -175,7 +175,7 @@ networking behaviour for CAN applications. Due to some requests from the RT-SocketCAN group the loopback optionally may be disabled for each separate socket. See sockopts from the CAN RAW sockets in :ref:`socketcan-raw-sockets`. -.. [*] you really like to have this when you're running analyser +.. [#f1] you really like to have this when you're running analyser tools like 'candump' or 'cansniffer' on the (same) node. -- 2.17.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/18] docs: uio-howto.rst: use a code block to solve a warning
/devel/v4l/docs/Documentation/driver-api/uio-howto.rst:715: WARNING: Unexpected indentation. Signed-off-by: Mauro Carvalho Chehab--- Documentation/driver-api/uio-howto.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/driver-api/uio-howto.rst b/Documentation/driver-api/uio-howto.rst index 92056c20e070..fb2eb73be4a3 100644 --- a/Documentation/driver-api/uio-howto.rst +++ b/Documentation/driver-api/uio-howto.rst @@ -711,7 +711,8 @@ The vmbus device regions are mapped into uio device resources: If a subchannel is created by a request to host, then the uio_hv_generic device driver will create a sysfs binary file for the per-channel ring buffer. -For example: +For example:: + /sys/bus/vmbus/devices/3811fe4d-0fa0-4b62-981a-74fc1084c757/channels/21/ring Further information -- 2.17.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/18] docs: core-api: add circular-buffers documentation
The circular-buffers.txt is already in ReST format. So, move it to the core-api guide, where it belongs. Signed-off-by: Mauro Carvalho Chehab--- Documentation/00-INDEX | 2 -- .../{circular-buffers.txt => core-api/circular-buffers.rst} | 0 Documentation/core-api/index.rst| 1 + Documentation/memory-barriers.txt | 2 +- Documentation/translations/ko_KR/memory-barriers.txt| 2 +- 5 files changed, 3 insertions(+), 4 deletions(-) rename Documentation/{circular-buffers.txt => core-api/circular-buffers.rst} (100%) diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index c6b81ef9827b..a9dd1384d8e3 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -80,8 +80,6 @@ cdrom/ - directory with information on the CD-ROM drivers that Linux has. cgroup-v1/ - cgroups v1 features, including cpusets and memory controller. -circular-buffers.txt - - how to make use of the existing circular buffer infrastructure clk.txt - info on the common clock framework cma/ diff --git a/Documentation/circular-buffers.txt b/Documentation/core-api/circular-buffers.rst similarity index 100% rename from Documentation/circular-buffers.txt rename to Documentation/core-api/circular-buffers.rst diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index d4d71ee564ae..3864de589126 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -26,6 +26,7 @@ Core utilities genalloc errseq printk-formats + circular-buffers Interfaces for kernel debugging === diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 983249906fc6..33b8bc9573f8 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -3083,7 +3083,7 @@ CIRCULAR BUFFERS Memory barriers can be used to implement circular buffering without the need of a lock to serialise the producer with the consumer. See: - Documentation/circular-buffers.txt + Documentation/core-api/circular-buffers.rst for details. diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt index 081937577c1a..2ec5fe0c9cf4 100644 --- a/Documentation/translations/ko_KR/memory-barriers.txt +++ b/Documentation/translations/ko_KR/memory-barriers.txt @@ -3023,7 +3023,7 @@ smp_mb() 가 아니라 virt_mb() 를 사용해야 합니다. 동기화에 락을 사용하지 않고 구현하는데에 사용될 수 있습니다. 더 자세한 내용을 위해선 다음을 참고하세요: - Documentation/circular-buffers.txt + Documentation/core-api/circular-buffers.rst = -- 2.17.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/18] mtd: rawnand.h: use nested union kernel-doc markups
Gets rid of those warnings and better document the parameters. ./include/linux/mtd/rawnand.h:752: warning: Function parameter or member 'timings.sdr' not described in 'nand_data_interface' ./include/linux/mtd/rawnand.h:817: warning: Function parameter or member 'buf' not described in 'nand_op_data_instr' ./include/linux/mtd/rawnand.h:817: warning: Function parameter or member 'buf.in' not described in 'nand_op_data_instr' ./include/linux/mtd/rawnand.h:817: warning: Function parameter or member 'buf.out' not described in 'nand_op_data_instr' ./include/linux/mtd/rawnand.h:863: warning: Function parameter or member 'ctx' not described in 'nand_op_instr' ./include/linux/mtd/rawnand.h:863: warning: Function parameter or member 'ctx.cmd' not described in 'nand_op_instr' ./include/linux/mtd/rawnand.h:863: warning: Function parameter or member 'ctx.addr' not described in 'nand_op_instr' ./include/linux/mtd/rawnand.h:863: warning: Function parameter or member 'ctx.data' not described in 'nand_op_instr' ./include/linux/mtd/rawnand.h:863: warning: Function parameter or member 'ctx.waitrdy' not described in 'nand_op_instr' ./include/linux/mtd/rawnand.h:1010: warning: Function parameter or member 'ctx' not described in 'nand_op_parser_pattern_elem' ./include/linux/mtd/rawnand.h:1010: warning: Function parameter or member 'ctx.addr' not described in 'nand_op_parser_pattern_elem' ./include/linux/mtd/rawnand.h:1010: warning: Function parameter or member 'ctx.data' not described in 'nand_op_parser_pattern_elem' ./include/linux/mtd/rawnand.h:1313: warning: Function parameter or member 'manufacturer.desc' not described in 'nand_chip' ./include/linux/mtd/rawnand.h:1313: warning: Function parameter or member 'manufacturer.priv' not described in 'nand_chip' ./include/linux/mtd/rawnand.h:848: WARNING: Unexpected indentation. Signed-off-by: Mauro Carvalho Chehab--- include/linux/mtd/rawnand.h | 26 ++ 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h index 5dad59b31244..b986f94906df 100644 --- a/include/linux/mtd/rawnand.h +++ b/include/linux/mtd/rawnand.h @@ -740,8 +740,9 @@ enum nand_data_interface_type { /** * struct nand_data_interface - NAND interface timing - * @type: type of the timing - * @timings: The timing, type according to @type + * @type: type of the timing + * @timings:The timing, type according to @type + * @timings.sdr: Use it when @type is %NAND_SDR_IFACE. */ struct nand_data_interface { enum nand_data_interface_type type; @@ -798,8 +799,9 @@ struct nand_op_addr_instr { /** * struct nand_op_data_instr - Definition of a data instruction * @len: number of data bytes to move - * @in: buffer to fill when reading from the NAND chip - * @out: buffer to read from when writing to the NAND chip + * @buf: buffer to fill + * @buf.in: buffer to fill when reading from the NAND chip + * @buf.out: buffer to read from when writing to the NAND chip * @force_8bit: force 8-bit access * * Please note that "in" and "out" are inverted from the ONFI specification @@ -842,9 +844,13 @@ enum nand_op_instr_type { /** * struct nand_op_instr - Instruction object * @type: the instruction type - * @cmd/@addr/@data/@waitrdy: extra data associated to the instruction. - *You'll have to use the appropriate element - *depending on @type + * @ctx: extra data associated to the instruction. You'll have to use the + *appropriate element depending on @type + * @ctx.cmd: use it if @type is %NAND_OP_CMD_INSTR + * @ctx.addr: use it if @type is %NAND_OP_ADDR_INSTR + * @ctx.data: use it if @type is %NAND_OP_DATA_IN_INSTR + * or %NAND_OP_DATA_OUT_INSTR + * @ctx.waitrdy: use it if @type is %NAND_OP_WAITRDY_INSTR * @delay_ns: delay the controller should apply after the instruction has been * issued on the bus. Most modern controllers have internal timings * control logic, and in this case, the controller driver can ignore @@ -997,7 +1003,9 @@ struct nand_op_parser_data_constraints { * struct nand_op_parser_pattern_elem - One element of a pattern * @type: the instructuction type * @optional: whether this element of the pattern is optional or mandatory - * @addr/@data: address or data constraint (number of cycles or data length) + * @ctx: address or data constraint + * @ctx.addr: address constraint (number of cycles) + * @ctx.data: data constraint (data length) */ struct nand_op_parser_pattern_elem { enum nand_op_instr_type type; @@ -1224,6 +1232,8 @@ int nand_op_parser_exec_op(struct nand_chip *chip, * devices. * @priv: [OPTIONAL] pointer to private chip data * @manufacturer: [INTERN] Contains manufacturer information + * @manufacturer.desc: [INTERN] Contains manufacturer's
[PATCH 11/18] docs: crypto_engine.rst: Fix two parse warnings
./Documentation/crypto/crypto_engine.rst:13: WARNING: Unexpected indentation. ./Documentation/crypto/crypto_engine.rst:15: WARNING: Block quote ends without a blank line; unexpected unindent. Signed-off-by: Mauro Carvalho Chehab--- Documentation/crypto/crypto_engine.rst | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/Documentation/crypto/crypto_engine.rst b/Documentation/crypto/crypto_engine.rst index 8272ac92a14f..1d56221dfe35 100644 --- a/Documentation/crypto/crypto_engine.rst +++ b/Documentation/crypto/crypto_engine.rst @@ -8,11 +8,13 @@ The crypto engine API (CE), is a crypto queue manager. Requirement --- -You have to put at start of your tfm_ctx the struct crypto_engine_ctx -struct your_tfm_ctx { +You have to put at start of your tfm_ctx the struct crypto_engine_ctx:: + + struct your_tfm_ctx { struct crypto_engine_ctx enginectx; ... -}; + }; + Why: Since CE manage only crypto_async_request, it cannot know the underlying request_type and so have access only on the TFM. So using container_of for accessing __ctx is impossible. -- 2.17.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 18/18] w1: w1_io.c: fix a kernel-doc warning
Add a blank line to avoid this Sphinx warning: ./drivers/w1/w1_io.c:197: WARNING: Definition list ends without a blank line; unexpected unindent. Signed-off-by: Mauro Carvalho Chehab--- drivers/w1/w1_io.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/w1/w1_io.c b/drivers/w1/w1_io.c index 075d120e7b88..0364d3329c52 100644 --- a/drivers/w1/w1_io.c +++ b/drivers/w1/w1_io.c @@ -194,6 +194,7 @@ static u8 w1_read_bit(struct w1_master *dev) * bit 0 = id_bit * bit 1 = comp_bit * bit 2 = dir_taken + * * If both bits 0 & 1 are set, the search should be restarted. * * Return:bit fields - see above -- 2.17.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/18] net: mac80211.h: fix a bad comment line
Sphinx produces a lot of errors like this: ./include/net/mac80211.h:2083: warning: bad line: > Signed-off-by: Mauro Carvalho Chehab--- include/net/mac80211.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/net/mac80211.h b/include/net/mac80211.h index d2279b2d61aa..b2f3a0c018e7 100644 --- a/include/net/mac80211.h +++ b/include/net/mac80211.h @@ -2080,7 +2080,7 @@ struct ieee80211_txq { * virtual interface might not be given air time for the transmission of * the frame, as it is not synced with the AP/P2P GO yet, and thus the * deauthentication frame might not be transmitted. - > + * * @IEEE80211_HW_DOESNT_SUPPORT_QOS_NDP: The driver (or firmware) doesn't * support QoS NDP for AP probing - that's most likely a driver bug. * -- 2.17.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/18] wait: wait.h: Get rid of a kernel-doc/Sphinx warnings
The flow diagram should be inside a code-block to avoid those warnings: ./include/linux/wait.h:110: WARNING: Block quote ends without a blank line; unexpected unindent. ./include/linux/wait.h:113: WARNING: Unexpected indentation. ./include/linux/wait.h:115: WARNING: Block quote ends without a blank line; unexpected unindent. This is easily done by using "::" instead of just ":". Signed-off-by: Mauro Carvalho Chehab--- include/linux/wait.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/wait.h b/include/linux/wait.h index d9f131ecf708..d907ed761a7f 100644 --- a/include/linux/wait.h +++ b/include/linux/wait.h @@ -101,7 +101,7 @@ init_waitqueue_func_entry(struct wait_queue_entry *wq_entry, wait_queue_func_t f * lead to sporadic and non-obvious failure. * * Use either while holding wait_queue_head::lock or when used for wakeups - * with an extra smp_mb() like: + * with an extra smp_mb() like:: * * CPU0 - wakerCPU1 - waiter * -- 2.17.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/18] Fix some build warnings/errors with Sphinx
I decided to give a try with Sphinx last stable version (1.17.4), and noticed several issues. The worse one was with the networking book: a non-standard footnote there with [*] instead of a number causes it to break PDF building. So, I took some spare time to address some warnings all over the tree, and moved a few text documents to a book. I with I had more time to move the other ones and to solve other warnings. Mauro Carvalho Chehab (18): docs: can.rst: fix a footnote reference docs: fix location of request_firmware & friends docs: */index.rst: Add newer documents to their respective index.rst docs: admin-guide: add bcache documentation docs: core-api: add cachetlb documentation docs: core-api: add cgroup-v2 documentation docs: core-api: add circular-buffers documentation docs: driver-api: add clk documentation net: mac80211.h: fix a bad comment line rcu: rcupdate.h: get rid of Sphinx warnings at rcu_pointer_handoff() docs: crypto_engine.rst: Fix two parse warnings time: timer.c: adjust a kernel-doc comment wait: wait.h: Get rid of a kernel-doc/Sphinx warnings fbdev: modedb.c: fix a kernel-doc markup iio: iio.h: use nested struct support on kernel-doc markup mtd: rawnand.h: use nested union kernel-doc markups docs: uio-howto.rst: use a code block to solve a warning w1: w1_io.c: fix a kernel-doc warning Documentation/00-INDEX| 10 --- .../{bcache.txt => admin-guide/bcache.rst}| 0 .../cgroup-v2.rst}| 0 Documentation/admin-guide/index.rst | 2 ++ .../admin-guide/kernel-parameters.txt | 2 +- .../{cachetlb.txt => core-api/cachetlb.rst} | 0 .../circular-buffers.rst} | 0 Documentation/core-api/index.rst | 2 ++ Documentation/crypto/crypto_engine.rst| 8 +++--- Documentation/crypto/index.rst| 1 + Documentation/dell_rbu.txt| 4 +-- Documentation/{clk.txt => driver-api/clk.rst} | 0 .../firmware/fallback-mechanisms.rst | 2 +- .../driver-api/firmware/request_firmware.rst | 17 +++- Documentation/driver-api/index.rst| 2 ++ Documentation/driver-api/infrastructure.rst | 2 +- Documentation/driver-api/uio-howto.rst| 3 ++- Documentation/memory-barriers.txt | 4 +-- Documentation/networking/can.rst | 4 +-- .../power/suspend-and-cpuhotplug.txt | 2 +- Documentation/process/index.rst | 1 + Documentation/security/index.rst | 2 ++ .../translations/ko_KR/memory-barriers.txt| 4 +-- drivers/video/fbdev/core/modedb.c | 22 drivers/w1/w1_io.c| 1 + include/linux/iio/iio.h | 24 - include/linux/mtd/rawnand.h | 26 +-- include/linux/rcupdate.h | 5 ++-- include/linux/wait.h | 2 +- include/net/mac80211.h| 2 +- kernel/time/timer.c | 14 +- 31 files changed, 93 insertions(+), 75 deletions(-) rename Documentation/{bcache.txt => admin-guide/bcache.rst} (100%) rename Documentation/{cgroup-v2.txt => admin-guide/cgroup-v2.rst} (100%) rename Documentation/{cachetlb.txt => core-api/cachetlb.rst} (100%) rename Documentation/{circular-buffers.txt => core-api/circular-buffers.rst} (100%) rename Documentation/{clk.txt => driver-api/clk.rst} (100%) -- 2.17.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/18] rcu: rcupdate.h: get rid of Sphinx warnings at rcu_pointer_handoff()
The code example at rcupdate.h currently produce lots of warnings: ./include/linux/rcupdate.h:572: WARNING: Unexpected indentation. ./include/linux/rcupdate.h:576: WARNING: Unexpected indentation. ./include/linux/rcupdate.h:580: WARNING: Block quote ends without a blank line; unexpected unindent. ./include/linux/rcupdate.h:582: WARNING: Block quote ends without a blank line; unexpected unindent. ./include/linux/rcupdate.h:582: WARNING: Inline literal start-string without end-string. Change it to a code-block. Signed-off-by: Mauro Carvalho Chehab--- include/linux/rcupdate.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h index 36360d07f25b..c890d10978fa 100644 --- a/include/linux/rcupdate.h +++ b/include/linux/rcupdate.h @@ -568,8 +568,8 @@ static inline void rcu_preempt_sleep_check(void) { } * This is simply an identity function, but it documents where a pointer * is handed off from RCU to some other synchronization mechanism, for * example, reference counting or locking. In C11, it would map to - * kill_dependency(). It could be used as follows: - * `` + * kill_dependency(). It could be used as follows:: + * * rcu_read_lock(); * p = rcu_dereference(gp); * long_lived = is_long_lived(p); @@ -580,7 +580,6 @@ static inline void rcu_preempt_sleep_check(void) { } * p = rcu_pointer_handoff(p); * } * rcu_read_unlock(); - *`` */ #define rcu_pointer_handoff(p) (p) -- 2.17.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/9] trace_uprobe: Support SDT markers having reference count (semaphore)
Hi Masami, On 05/04/2018 07:51 PM, Ravi Bangoria wrote: > >>> +} >>> + >>> +static void sdt_increment_ref_ctr(struct trace_uprobe *tu) >>> +{ >>> + struct uprobe_map_info *info; >>> + >>> + uprobe_down_write_dup_mmap(); >>> + info = uprobe_build_map_info(tu->inode->i_mapping, >>> + tu->ref_ctr_offset, false); >>> + if (IS_ERR(info)) >>> + goto out; >>> + >>> + while (info) { >>> + down_write(>mm->mmap_sem); >>> + >>> + if (sdt_find_vma(tu, info->mm, info->vaddr)) >>> + sdt_update_ref_ctr(info->mm, info->vaddr, 1); >> Don't you have to handle the error to map pages here? > Correct.. I think, I've to feedback error code to probe_event_{enable|disable} > and handler failure there. I looked at this. Actually, It looks difficult to feedback errors to probe_event_{enable|disable}, esp. in the mmap() case. Is it fine if we just warn sdt_update_ref_ctr() failures in dmesg? I'm doing this in [PATCH 7]. (Though, it makes more sense to do that in [PATCH 6], will change it in next version). Any better ideas? BTW, same issue exists for normal uprobe. If uprobe_mmap() fails, there is no feedback to trace_uprobe and no warnigns in dmesg as well !! There was a patch by Naveen to warn such failures in dmesg but that didn't go in: https://lkml.org/lkml/2017/9/22/155 Also, I'll add a check in sdt_update_ref_ctr() to make sure reference counter never goes to negative incase increment fails but decrement succeeds. OTOH, if increment succeeds but decrement fails, the counter remains >0 but there is no harm as such, except we will execute some unnecessary code. Thanks, Ravi -- 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] vfio: fix documentation
On Mon, 7 May 2018 11:02:10 +0800 "dongbo (E)"wrote: > From: Dong Bo > > Update vfio_add_group_dev description to match the current API. > > Signed-off-by: Dong Bo > --- > Documentation/vfio.txt | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt > index ef6a511..f1a4d3c 100644 > --- a/Documentation/vfio.txt > +++ b/Documentation/vfio.txt > @@ -252,15 +252,14 @@ into VFIO core. When devices are bound and unbound to > the driver, > the driver should call vfio_add_group_dev() and vfio_del_group_dev() > respectively:: > > - extern int vfio_add_group_dev(struct iommu_group *iommu_group, > - struct device *dev, > + extern int vfio_add_group_dev(struct device *dev, > const struct vfio_device_ops *ops, > void *device_data); > > extern void *vfio_del_group_dev(struct device *dev); > > vfio_add_group_dev() indicates to the core to begin tracking the > -specified iommu_group and register the specified dev as owned by > +iommu_group of the specified dev and register the dev as owned by > a VFIO bus driver. The driver provides an ops structure for callbacks > similar to a file operations structure:: > Reviewed-by: Cornelia Huck -- 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