Re: [PATCH v2 0/4] ipmi: bt-i2c: added IPMI Block Transfer over I2C

[Brendan Higgins]

On Sat, Aug 5, 2017 at 3:23 PM, Corey Minyard  wrote:
> On 08/04/2017 08:18 PM, Brendan Higgins wrote:
>>
>> This patchset introduces IPMI Block Transfer over I2C (BT-I2C), which has
>> the
>> same semantics as IPMI Block Transfer except it done over I2C.
>>
>> For the OpenBMC people, this is based on an RFC:
>> https://lists.ozlabs.org/pipermail/openbmc/2016-September/004505.html
>>
>> The documentation discusses the reason for this in greater detail, suffice
>> it to
>> say SSIF cannot be correctly implemented on some naive I2C devices. There
>> are
>> some additional reasons why we don't like SSIF, but those are again
>> covered in
>> the documentation for all those who are interested.
>
>
> I'm not terribly excited about this.  A few notes:

I was afraid so, alas.

>
> SMBus alerts are fairly broken in Linux right now.  I have a patch to fix
> this at:
> https://github.com/cminyard/linux-ipmi/commit/48136176ce1890f99857c73e0ace5bd8dfb61fbf
> I haven't been able to get much traction getting anyone to care.

Yeah, I have some work I would like to do there as well.

>
> The lack of a NACK could be worked around fairly easily in the current
> driver.  It looks like you
> are just returning a message too short to be valid.  That's easy.  I think
> it's a rather major
> deficiency in the hardware to not be able to NACK something, but that is
> what it is.

Right, we actually have multiple pieces of hardware that do not support
NACKing correctly. The most frustrating piece is the Aspeed chip which
does not provide and facility for arbitrary NACKs to be generated on the
slave side.

>
> What you have is not really BT over I2C.  You have just added a sequence
> number to the
> IPMI messages and dropped the SMBus command.  Other interfaces have sequence
> numbers,
> too.  Calling it BT is a little over the top.

Fair point, maybe ISIF (I2C System Interface)? I don't have strong feelings
about the name.

>
> Do you really need the performance required by having multiple outstanding
> messages?
> That adds a lot of complexity, if it's unnecessary it's just a waste.  The
> IPMI work on top
> of interfaces does not really require that much performance, it's just
> reading sensors,
> FRU data, and such.  Perhaps you have a reason, but I fail to see
> why it's really that big a deal.  The BT interface has this ability, but the
> driver does not
> take advantage of it and nobody has complained.
>

Yes, we do have some platforms which only have IPMI as a standard interface
and we are abusing some OEM commands to do some things that we probably
should not do with IPMI like doing firmware updates. Also, we have some
commands which take a really long time to complete (> 1s). Admittedly, this is
abusing IPMI to solve problems which should probably be solved elsewhere;
nevertheless, it is a feature we are actually using. And having an option to use
sequence numbers if definitely nice from our perspective.

We will probably want to improve the block transfer driver at some
point as well.

> And I don't understand the part about OpenBMC making use of sequence
> numbers.
> Why does that matter for this interface?  It's the host side that would care
> about
> that, the host would stick the numbers in and the slave would return it.  If
> you are
> using sequence numbers in OpenBMC, which sounds quite reasonable, I would
> think
> it would be a bad idea to to trust that the host would give you good
> sequence
> numbers.
>

I think, I illustrated the use case above, but to reiterate, the
desire is to have
multiple messages in flight at the same time because some messages take
a long time to service.

> Plus, with multiple outstanding messages, you really need to limit it.  A
> particular BMC
> may not be able to handle it the full 256, and the ability to have that many
> messages
> outstanding is probably not a good thing.
>

It is going to depend on the BMC of course; nevertheless, I would be willing
to implement a configurable limit.

> If you really need multiple outstanding messages, the host side IPMI message
> handler
> needs to change to allow that.  It's doable, and I know how, I just haven't
> seen the
> need.
>

Sure, we would also like SMBus alert support, but I figured it was probably
best to discuss this with you before we go too far down that path.

> I would agree that the multi-part messages in SSIF is a big pain and and a
> lot of
> unnecessary complexity.  I believe it is there to accommodate host hardware
> that is
> limited.  But SMBus can have 255 byte messages and there's no arbitrary
> limit on
> I2C.  It is the way of IPMI to support the least common denominator.
>
> Your interface will only work on Linux.  Other OSes (unless they choose to
> implement this
> driver) will be unable to use your BMC.  Of course there's the NACK issue,
> but that's a
> big difference, and it would probably still work with existing drivers on
> other OSes.

I hope I did not send the message that we are planning 

Re: [PATCH v4] printk: Add monotonic, boottime, and realtime timestamps

[Sergey Senozhatsky]

On (08/07/17 11:52), Prarit Bhargava wrote:
[..]
> +/**
> + * enum printk_time_type - Timestamp types for printk() messages.
> + * @PRINTK_TIME_DISABLE: No time stamp.
> + * @PRINTK_TIME_LOCAL: Local hardware clock timestamp.
> + * @PRINTK_TIME_BOOT: Boottime clock timestamp.
> + * @PRINTK_TIME_MONO: Monotonic clock timestamp.
> + * @PRINTK_TIME_REAL: Realtime clock timestamp.  On 32-bit
> + * systems selecting the real clock printk timestamp may lead to unlikely
> + * situations where a timestamp is wrong because the real time offset is read
> + * without the protection of a sequence lock in the call to 
> ktime_get_log_ts()
> + * in printk_get_ts() below.
> + */
> +enum printk_time_type {
> + PRINTK_TIME_DISABLE = 0,
> + PRINTK_TIME_LOCAL = 1,
> + PRINTK_TIME_BOOT = 2,
> + PRINTK_TIME_MONO = 3,
> + PRINTK_TIME_REAL = 4,
> +};

may be call the entire thing 'timestamp surces' or something?

[..]
> + if (strlen(param) == 1) {
> + /* Preserve legacy boolean settings */
> + if (!strcmp("0", param) || !strcmp("n", param) ||
> + !strcmp("N", param))
> + _printk_time = PRINTK_TIME_DISABLE;
> + if (!strcmp("1", param) || !strcmp("y", param) ||
> + !strcmp("Y", param))
> + _printk_time = PRINTK_TIME_LOCAL;
> + }
> + if (_printk_time == -1) {
> + for (stamp = 0; stamp <= 4; stamp++) {
> + if (!strncmp(printk_time_str[stamp], param,
> +  strlen(param))) {
> + _printk_time = stamp;
> + break;
> + }
> + }
> + }

you can use match_string() here.

> + if (_printk_time == -1) {
> + pr_warn("printk: invalid timestamp value %s\n", param);
> + return -EINVAL;
> + }

`invalid timestamp value' is confusing.


> + } else if ((printk_time_setting != _printk_time) &&
> +(_printk_time != 0)) {
> + pr_warn("printk: timestamp can only be set to 0(disabled) or 
> %s\n",
> + printk_time_str[printk_time_setting]);

ditto.


> + return -EINVAL;
> + }
> +
> + printk_time = _printk_time;
> + pr_info("printk: timestamp set to %s\n", printk_time_str[printk_time]);

ditto.


[..]

> +static u64 printk_get_ts(void)
> +{
> + u64 mono, offset_real;
> +
> + if (printk_time <= PRINTK_TIME_LOCAL)
> + return local_clock();
> +
> + if (printk_time == PRINTK_TIME_BOOT)
> + return ktime_get_boot_log_ts();
> +
> + mono = ktime_get_real_log_ts(_real);
> +
> + if (printk_time == PRINTK_TIME_MONO)
> + return mono;
> +
> + return mono + offset_real;
> +}

this looks hard...

> +static int printk_time;
> +static int printk_time_setting;

how about s/printk_time_setting/printk_time_source/? or something similar?

-ss
--
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 v4] printk: Add monotonic, boottime, and realtime timestamps

[Paul E. McKenney]

On Mon, Aug 07, 2017 at 04:06:09PM -0400, Prarit Bhargava wrote:
> 
> 
> On 08/07/2017 02:47 PM, John Stultz wrote:
> > On Mon, Aug 7, 2017 at 11:04 AM, Prarit Bhargava  wrote:
> >> On 08/07/2017 12:52 PM, John Stultz wrote:
> >>> Still not quite following why you're updating all the defconfigs. I'd
> >>> make sure the Kconfig default settings are right, and leave updating
> >>> the defconfig to arch/device maintainers. It adds a lot of noise to
> >>> the patch.
> >>
> >> Hmm ... I thought it was up to the patch submitter to make sure that
> >> 'make defconfig' still worked?  Are you sure I can leave that broken?
> >>
> >> /me *really* doesn't want to get yelled at by every arch maintainer.
> > 
> > No. Don't break systems, but at the same time, can't you use the
> > default value in Kconfig to set it properly so the old defconfig
> > settings don't really matter?
> > 
> > Apologies if I've not followed the issue properly, but it is odd, as
> > I'm not sure I can think of a patch I've seen before that had so much
> > defconfig noise in it.  Again, I've not looked into it closely, so it
> > may just be my own ignorance, but it makes me suspect there is a
> > better way.
> > 
> 
> peterz?  Want to offer a suggestion?  The issue is that I'm changing a bool
> config option to an int and that impacts all the arch's defconfigs.  John 
> points
> out that this is a lot of churn and we're both wondering if there's a better 
> way
> to do the configs.

The usual approach is to keep the old bool Kconfig option, and add another
int Kconfig option that depends on the original one.  The tests for
the int value get a bit more complex, but one way to handle this is to
define a cpp macro something like the following:

#ifdef CONFIG_OLD_OPTION
#define CPP_NEW_OPTION 0
#else
#define CPP_NEW_OPTION CONFIG_NEW_OPTION
#endif

Then use CPP_NEW_OPTION, where zero means disabled and other numbers
select the available options.

Adjust to suit depending on what values mean what.

Another approach is to make the range of the new Kconfig option
depend on the old option:

config NEW_OPTION
int "your description here"
range 1 5 if OLD_OPTION
range 0 0 if !OLD_OPTION
default 0
help
  your help here

Again, adjust to suit depending on what values mean what.

Thanx, Paul

--
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 v4 resend 1/2] rtmutex: update rt-mutex-design

[Jonathan Corbet]

On Mon, 31 Jul 2017 09:53:01 +0800
Alex Shi  wrote:

> On 07/31/2017 09:50 AM, Alex Shi wrote:
> > -Reviewers:  Ingo Molnar, Thomas Gleixner, Thomas Duetsch, and Randy Dunlap
> > +Original Reviewers:  Ingo Molnar, Thomas Gleixner, Thomas Duetsch, and
> > +Randy Dunlap
> > +Update (7/6/2017) Reviewers: Steven Rostedt and Sebastian Siewior
> >
> 
> Hi Peter,
> 
> This patch had been reviewed and acked by Sebastian and Steven. Do you
> still need a official 'reviewed-by' from them?

Given this, I've been assuming that these changes aren't meant to go
through the docs tree; let me know if I should pick them up instead.

Thanks,

jon
--
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] docs: driver-api: Remove trailing blank line

[Jonathan Corbet]

On Mon, 24 Jul 2017 11:01:31 +0200
Thierry Reding  wrote:

> From: Thierry Reding 
> 
> There's no use for this blank line at the end of the file. Remove it.
> 
> Signed-off-by: Thierry Reding 
> ---
>  Documentation/driver-api/miscellaneous.rst | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/Documentation/driver-api/miscellaneous.rst 
> b/Documentation/driver-api/miscellaneous.rst
> index 8da7d115bafc..304ffb146cf9 100644
> --- a/Documentation/driver-api/miscellaneous.rst
> +++ b/Documentation/driver-api/miscellaneous.rst
> @@ -47,4 +47,3 @@ used by one consumer at a time.
>  
>  .. kernel-doc:: drivers/pwm/core.c
> :export:
> -   

Applied - the scourge of the extra blank line is no more.

Thanks,

jon
--
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] scripts/sphinx-pre-install: add minimum support for RHEL

[Jonathan Corbet]

On Mon, 24 Jul 2017 09:09:24 -0300
Mauro Carvalho Chehab  wrote:

> RHEL 7.x and clone distros are shipped with Sphinx 1.1.x,
> with is incompatible with Kernel ReST markups.
> 
> So, on those systems, the only alternative is to install
> it via a Python virtual environment.
> 
> While seeking for "pip" on CentOS 7.3, I noticed that it
> is not really needed, as python-virtualenv has its version
> packaged there already. So, remove this from the list of
> requirements for all distributions.
> 
> With regards to PDF, twe need at least texlive-tabulary
> extension, but that is not shipped there (at least on
> CentOS). So, disable PDF packages as a hole.
> 
> Please notice, however, that texlive + amsmath is needed for
> ReST to properly handle ReST ".. math::" tags. Yet, Sphinx
> fall back to display the LaTeX math expressions as-is, if
> such extension is not available.
> 
> So, let's just disable all texlive packages as a hole.

I've applied this, finally.  Couldn't resist the temptation to fix "as a
whole" while I was at it :)

Thanks,

jon
--
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] kbuild: Update example for ccflags-y usage

[Jonathan Corbet]

On Mon, 24 Jul 2017 17:27:05 +0200
Sedat Dilek  wrote:

> The old example to describe ccflags-y usage is no more valid.
> 
> Signed-off-by: Sedat Dilek 

I've applied this; had to clean up some whitespace weirdness on the way.

Thanks,

jon
--
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] docs/features: parisc implements tracehook

[Jonathan Corbet]

On Fri, 4 Aug 2017 11:28:39 +0100
James Hogan  wrote:

> Since commit 64e2a42bca12 ("parisc: Add ARCH_TRACEHOOK and regset
> support") in v4.7, parisc selects HAVE_ARCH_TRACEHOOK, so update its
> entry in Documentation/features from TODO to ok.

Applied to the docs tree, thanks.

jon
--
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 v4] printk: Add monotonic, boottime, and realtime timestamps

[Prarit Bhargava]

On 08/07/2017 02:47 PM, John Stultz wrote:
> On Mon, Aug 7, 2017 at 11:04 AM, Prarit Bhargava  wrote:
>> On 08/07/2017 12:52 PM, John Stultz wrote:
>>> Still not quite following why you're updating all the defconfigs. I'd
>>> make sure the Kconfig default settings are right, and leave updating
>>> the defconfig to arch/device maintainers. It adds a lot of noise to
>>> the patch.
>>
>> Hmm ... I thought it was up to the patch submitter to make sure that
>> 'make defconfig' still worked?  Are you sure I can leave that broken?
>>
>> /me *really* doesn't want to get yelled at by every arch maintainer.
> 
> No. Don't break systems, but at the same time, can't you use the
> default value in Kconfig to set it properly so the old defconfig
> settings don't really matter?
> 
> Apologies if I've not followed the issue properly, but it is odd, as
> I'm not sure I can think of a patch I've seen before that had so much
> defconfig noise in it.  Again, I've not looked into it closely, so it
> may just be my own ignorance, but it makes me suspect there is a
> better way.
> 

peterz?  Want to offer a suggestion?  The issue is that I'm changing a bool
config option to an int and that impacts all the arch's defconfigs.  John points
out that this is a lot of churn and we're both wondering if there's a better way
to do the configs.

P.
--
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 v4] printk: Add monotonic, boottime, and realtime timestamps

[John Stultz]

On Mon, Aug 7, 2017 at 11:04 AM, Prarit Bhargava  wrote:
> On 08/07/2017 12:52 PM, John Stultz wrote:
>> Still not quite following why you're updating all the defconfigs. I'd
>> make sure the Kconfig default settings are right, and leave updating
>> the defconfig to arch/device maintainers. It adds a lot of noise to
>> the patch.
>
> Hmm ... I thought it was up to the patch submitter to make sure that
> 'make defconfig' still worked?  Are you sure I can leave that broken?
>
> /me *really* doesn't want to get yelled at by every arch maintainer.

No. Don't break systems, but at the same time, can't you use the
default value in Kconfig to set it properly so the old defconfig
settings don't really matter?

Apologies if I've not followed the issue properly, but it is odd, as
I'm not sure I can think of a patch I've seen before that had so much
defconfig noise in it.  Again, I've not looked into it closely, so it
may just be my own ignorance, but it makes me suspect there is a
better way.


>>> +u64 ktime_get_real_log_ts(u64 *offset_real)
>>> +{
>>> +   *offset_real = ktime_to_ns(tk_core.timekeeper.offs_real);
>>> +
>>> +   if (timekeeping_active)
>>> +   return ktime_get_mono_fast_ns();
>>> +   else
>>> +   return local_clock();
>>> +}
>>> +
>>> +u64 ktime_get_boot_log_ts(void)
>>> +{
>>> +   if (timekeeping_active)
>>> +   return ktime_get_boot_fast_ns();
>>> +   else
>>> +   return local_clock();
>>> +}
>>
>> This feels a little tacked on and duplicative.  I'd suggest having one
>> function that returns the offset_real and offset_boot or have a
>> separate get_mono_log_ts() so its at least consistent.
>
> I have a better suggestion that I was toying with -- exporting
> timekeeping_active and using the existing ktime_get_mono|boot|real|_fast_ns()
> functions with a function pointer would simplify this code.

Yea. That sounds cleaner.


>> Additionally,
>> in the commit message, you call out the lack of locking between
>> grabing the offs_real and calling get_mono_fast_ns(), but I worry it
>> may be particularly problematic on 32bit systems, and you don't have
>> any notes in the actual code about it (it looks like an oversight).
>>
>
> I was told to move that comment to the kdoc description by Luis R. Rodriguez.

You can have it both ways. :)  Its just without any mention near the
function, it just looks buggy (well, because it technically is), so
either we should fix it properly or at least document that its
intentionally buggy (which again, doesn't feel great here - we already
have lots of caveats around the _fast_ns() accessors, so this is
layering subtle breakage on top of other subtle behavior).


>> Also, when timekeeping_active flips over, and we change from local
>> clock to the specified clock, do we see a discontinuity in the log? I
>> know folks use to gripe about that back in the day.
>>
>
> I have tested this across many systems and haven't seen a discontinunity
> yet.  I've done both large and small cpu footprint systems and haven't seen
> anything like that.

Ok.

thanks
-john
--
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] printk: Add boottime and real timestamps

[Prarit Bhargava]

On 08/07/2017 01:14 PM, Luis R. Rodriguez wrote:

> 
> Note printk_late_init() is a late_initcall(). This means if the
> printk_time_setting was disabled it will take a while to enable it. Enabling 
> it
> is done at the device_initcall(), so if printk setting is disabled but a user
> enables it with a toggle of the module param there is a period of time during
> which time resolution would be different. 

I'm not sure I follow your comment.  Could you elaborate with an example of
what you think is going wrong or might be confusing?

P.

> Perhaps for some this is not useful
> information but for others I think this would be very valuable.
> 
> There is also something to say about the time in between initializing access
> to ktime_get_mono_fast_ns(), how early is this reliable?
> 
> All these things could be mentioned on the documentation.
> 
>   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 v4] printk: Add monotonic, boottime, and realtime timestamps

[Prarit Bhargava]

On 08/07/2017 12:58 PM, Mark Salyzyn wrote:
> On 08/07/2017 08:52 AM, Prarit Bhargava wrote:
>> diff --git a/arch/arm/configs/aspeed_g4_defconfig
>> b/arch/arm/configs/aspeed_g4_defconfig
>> index cfc2465e8b77..5f3c50914e92 100644
>> --- a/arch/arm/configs/aspeed_g4_defconfig
>> +++ b/arch/arm/configs/aspeed_g4_defconfig
>> @@ -162,7 +162,7 @@ CONFIG_JFFS2_FS_XATTR=y
>>   CONFIG_UBIFS_FS=y
>>   CONFIG_SQUASHFS=y
>>   CONFIG_SQUASHFS_XZ=y
>> -CONFIG_PRINTK_TIME=y
>> +CONFIG_PRINTK_TIME_LOCAL=y
>>   CONFIG_DYNAMIC_DEBUG=y
>>   CONFIG_STRIP_ASM_SYMS=y
>>   CONFIG_DEBUG_FS=y
> Many have had misgivings, let me try another pass at this.
> 
> We (royal we) should really look into adjusting configuration parsing to allow
> an easy transition from boolean to selection ... I am sure this is not the 
> first
> time bistate/tristate was moved to a number.
> 
> An idea? Maybe look into a way to deal with this to use something _other_ than
> CONFIG_PRINTK_TIME to hold the selection, and keep a (hidden/legacy?)
> CONFIG_PRINTK_TIME that when selected sets CONFIG_PRINTK_TIME_LOCAL, and 
> switch
> to _not_ CONFIG_PRINTK_TIME_DISABLE as the internal mechanical replacement for
> it. I do not know how disruptive this will be, but is worth it if the codebase
> supports it, and legacy config retained?

I looked for one but couldn't find one.  The kernel is a big place, though, and
perhaps it already exists :/.

>> +
>> +static int printk_time_set(const char *val, const struct kernel_param *kp)
>> +{
>> +char *param = strstrip((char *)val);
>> +int _printk_time = -1;
>> +int stamp;
>> +
>> +if (strlen(param) == 1) {
>> +/* Preserve legacy boolean settings */
>> +if (!strcmp("0", param) || !strcmp("n", param) ||
> if strlen(param) == 1, then param[0] == '0' etc works fine and is KISS.
>> +/*
>> + * Only allow enabling and disabling of the current printk_time
>> + * setting.  Changing it from one setting to another confuses
>> + * userspace.
>> + */
>> +if (printk_time_setting == PRINTK_TIME_DISABLE) {
>> +printk_time_setting = _printk_time;
>> +} else if ((printk_time_setting != _printk_time) &&
>> +   (_printk_time != 0)) {
>> +pr_warn("printk: timestamp can only be set to 0(disabled) or %s\n",
>> +printk_time_str[printk_time_setting]);
>> +return -EINVAL;
>> +}
> I agree with the restriction in the general case.  However (as hinted at
> before() #ifdef CONFIG_PRINTK_TIME_RESTRICT (default y, or #ifndef
> CONFIG_PRINTK_TIME_DEBUG default n) around this will allow us users to choose 
> if
> we are confused or not. I can see being able to change it on the fly as an
> option. Especially since we have /sys/module/printk/parameters/time.

Yeah, but I think that should be a later enhancement.

P.

> 
> -- Mark
--
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 v4] printk: Add monotonic, boottime, and realtime timestamps

[Prarit Bhargava]

On 08/07/2017 12:52 PM, John Stultz wrote:
> On Mon, Aug 7, 2017 at 8:52 AM, Prarit Bhargava  wrote:
>> printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock
>> timestamp to printk messages.  The local hardware clock loses time each
>> day making it difficult to determine exactly when an issue has occurred in
>> the kernel log, and making it difficult to determine how kernel and
>> hardware issues relate to each other in real time.
>>
>> Make printk output different timestampes by adding options for no
>> timestamp, the local hardware clock, the monotonic clock, the boottime
>> clock, and the real clock.  Allow a user to pick one of the clocks by
>> using the printk.time kernel parameter.  Output the type of clock in
>> /sys/module/printk/parameters/time so userspace programs can interpret the
>> timestamp.
>>
>> Real clock & 32-bit systems:  Selecting the real clock printk timestamp may
>> lead to unlikely situations where a timestamp is wrong because the real time
>> offset is read without the protection of a sequence lock in the call to
>> ktime_get_log_ts() in printk_get_ts().
>>
>> v2: Use peterz's suggested Kconfig options.  Merge patchset together.
>> Fix i386 !CONFIG_PRINTK builds.
>>
>> v3: Fixed x86_64_defconfig. Added printk_time_type enum and
>> printk_time_str for better output. Added BOOTTIME clock functionality.
>>
>> v4: Fix messages, add additional printk.time options, and fix configs.
>>
>> Signed-off-by: Prarit Bhargava 
>> Cc: Mark Salyzyn 
>> Cc: Jonathan Corbet 
>> Cc: Petr Mladek 
>> Cc: Sergey Senozhatsky 
>> Cc: Steven Rostedt 
>> Cc: John Stultz 
>> Cc: Thomas Gleixner 
>> Cc: Stephen Boyd 
>> Cc: Andrew Morton 
>> Cc: Greg Kroah-Hartman 
>> Cc: "Paul E. McKenney" 
>> Cc: Christoffer Dall 
>> Cc: Deepa Dinamani 
>> Cc: Ingo Molnar 
>> Cc: Joel Fernandes 
>> Cc: Prarit Bhargava 
>> Cc: Kees Cook 
>> Cc: Peter Zijlstra 
>> Cc: Geert Uytterhoeven 
>> Cc: "Luis R. Rodriguez" 
>> Cc: Nicholas Piggin 
>> Cc: "Jason A. Donenfeld" 
>> Cc: Olof Johansson 
>> Cc: Josh Poimboeuf 
>> Cc: linux-doc@vger.kernel.org
>> ---
>>  Documentation/admin-guide/kernel-parameters.txt|   6 +-
>>  arch/arm/configs/aspeed_g4_defconfig   |   2 +-
>>  arch/arm/configs/aspeed_g5_defconfig   |   2 +-
>>  arch/arm/configs/axm55xx_defconfig |   2 +-
>>  arch/arm/configs/bcm2835_defconfig |   2 +-
>>  arch/arm/configs/colibri_pxa270_defconfig  |   2 +-
>>  arch/arm/configs/colibri_pxa300_defconfig  |   2 +-
>>  arch/arm/configs/dove_defconfig|   2 +-
>>  arch/arm/configs/efm32_defconfig   |   2 +-
>>  arch/arm/configs/exynos_defconfig  |   2 +-
>>  arch/arm/configs/ezx_defconfig |   2 +-
>>  arch/arm/configs/h5000_defconfig   |   2 +-
>>  arch/arm/configs/hisi_defconfig|   2 +-
>>  arch/arm/configs/imote2_defconfig  |   2 +-
>>  arch/arm/configs/imx_v6_v7_defconfig   |   2 +-
>>  arch/arm/configs/keystone_defconfig|   2 +-
>>  arch/arm/configs/lpc18xx_defconfig |   2 +-
>>  arch/arm/configs/magician_defconfig|   2 +-
>>  arch/arm/configs/mmp2_defconfig|   2 +-
>>  arch/arm/configs/moxart_defconfig  |   2 +-
>>  arch/arm/configs/mps2_defconfig|   2 +-
>>  arch/arm/configs/multi_v7_defconfig|   2 +-
>>  arch/arm/configs/mvebu_v7_defconfig|   2 +-
>>  arch/arm/configs/mxs_defconfig |   2 +-
>>  arch/arm/configs/omap2plus_defconfig   |   2 +-
>>  arch/arm/configs/pxa168_defconfig  |   2 +-
>>  arch/arm/configs/pxa3xx_defconfig  |   2 +-
>>  arch/arm/configs/pxa910_defconfig  |   2 +-
>>  arch/arm/configs/pxa_defconfig |   2 +-
>>  arch/arm/configs/qcom_defconfig|   2 +-
>>  arch/arm/configs/raumfeld_defconfig|   2 +-
>>  arch/arm/configs/shmobile_defconfig|   2 +-
>>  arch/arm/configs/socfpga_defconfig |   2 +-
>>  arch/arm/configs/stm32_defconfig   |   2 +-
>>  arch/arm/configs/sunxi_defconfig   |   2 +-
>>  arch/arm/configs/tango4_defconfig  |   2 +-
>>  arch/arm/configs/tegra_defconfig  

Re: [PATCH v4] printk: Add monotonic, boottime, and realtime timestamps

[Peter Zijlstra]

On Mon, Aug 07, 2017 at 11:52:42AM -0400, Prarit Bhargava wrote:
> +static u64 printk_get_ts(void)
> +{
> + u64 mono, offset_real;
> +
> + if (printk_time <= PRINTK_TIME_LOCAL)
> + return local_clock();
> +
> + if (printk_time == PRINTK_TIME_BOOT)
> + return ktime_get_boot_log_ts();
> +
> + mono = ktime_get_real_log_ts(_real);
> +
> + if (printk_time == PRINTK_TIME_MONO)
> + return mono;
> +
> + return mono + offset_real;
> +}
>  
>  static size_t print_time(u64 ts, char *buf)
>  {
> @@ -1643,7 +1750,7 @@ static bool cont_add(int facility, int level, enum 
> log_flags flags, const char *
>   cont.facility = facility;
>   cont.level = level;
>   cont.owner = current;
> - cont.ts_nsec = local_clock();
> + cont.ts_nsec = printk_get_ts();
>   cont.flags = flags;
>   }
>  

So you really want to do all those branches every single time you
printk() ? I know printk() is somewhat of a slow path, but shees that's
ugly.

Why not have that setup function of yours set a function pointer?
--
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 v4] printk: Add monotonic, boottime, and realtime timestamps

[Peter Zijlstra]

On Mon, Aug 07, 2017 at 09:52:10AM -0700, John Stultz wrote:
> On Mon, Aug 7, 2017 at 8:52 AM, Prarit Bhargava  wrote:
> > +u64 ktime_get_real_log_ts(u64 *offset_real)
> > +{
> > +   *offset_real = ktime_to_ns(tk_core.timekeeper.offs_real);
> > +
> > +   if (timekeeping_active)
> > +   return ktime_get_mono_fast_ns();
> > +   else
> > +   return local_clock();
> > +}
> > +
> > +u64 ktime_get_boot_log_ts(void)
> > +{
> > +   if (timekeeping_active)
> > +   return ktime_get_boot_fast_ns();
> > +   else
> > +   return local_clock();
> > +}
> 
> This feels a little tacked on and duplicative.  I'd suggest having one
> function that returns the offset_real and offset_boot or have a
> separate get_mono_log_ts() so its at least consistent.   Additionally,
> in the commit message, you call out the lack of locking between
> grabing the offs_real and calling get_mono_fast_ns(), but I worry it
> may be particularly problematic on 32bit systems, and you don't have
> any notes in the actual code about it (it looks like an oversight).
> 
> Also, when timekeeping_active flips over, and we change from local
> clock to the specified clock, do we see a discontinuity in the log? I
> know folks use to gripe about that back in the day.

Yeah, yuck, this smells. Please don't mix clocks like this.

I expect all you want is to avoid the explosion you get from calling the
fast things too early, right? Please use the below, which should result
in it returning 0.

---
 kernel/time/timekeeping.c | 47 +--
 1 file changed, 33 insertions(+), 14 deletions(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index cedafa008de5..d111039e0245 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -60,8 +60,39 @@ struct tk_fast {
struct tk_read_base base[2];
 };
 
-static struct tk_fast tk_fast_mono cacheline_aligned;
-static struct tk_fast tk_fast_raw  cacheline_aligned;
+/* Suspend-time cycles value for halted fast timekeeper. */
+static u64 cycles_at_suspend;
+
+static u64 dummy_clock_read(struct clocksource *cs)
+{
+   return cycles_at_suspend;
+}
+
+static struct clocksource dummy_clock = {
+   .read = dummy_clock_read,
+};
+
+static struct tk_fast tk_fast_mono cacheline_aligned = {
+   .base = {
+   (struct tk_read_base){
+   .clock = _clock,
+   },
+   (struct tk_read_base){
+   .clock = _clock,
+   },
+   },
+};
+
+static struct tk_fast tk_fast_raw  cacheline_aligned = {
+   .base = {
+   (struct tk_read_base){
+   .clock = _clock,
+   },
+   (struct tk_read_base){
+   .clock = _clock,
+   },
+   },
+};
 
 /* flag for if timekeeping is suspended */
 int __read_mostly timekeeping_suspended;
@@ -477,18 +508,6 @@ u64 notrace ktime_get_boot_fast_ns(void)
 }
 EXPORT_SYMBOL_GPL(ktime_get_boot_fast_ns);
 
-/* Suspend-time cycles value for halted fast timekeeper. */
-static u64 cycles_at_suspend;
-
-static u64 dummy_clock_read(struct clocksource *cs)
-{
-   return cycles_at_suspend;
-}
-
-static struct clocksource dummy_clock = {
-   .read = dummy_clock_read,
-};
-
 /**
  * halt_fast_timekeeper - Prevent fast timekeeper from accessing clocksource.
  * @tk: Timekeeper to snapshot.
--
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] printk: Add boottime and real timestamps

[Luis R. Rodriguez]

On Thu, Aug 03, 2017 at 09:18:44PM -0400, Prarit Bhargava wrote:
> index fc47863f629c..8f093dd0a733 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1202,8 +1204,119 @@ static inline void boot_delay_msec(int level)
>  }
>  #endif
>  
> -static bool printk_time = IS_ENABLED(CONFIG_PRINTK_TIME);
> -module_param_named(time, printk_time, bool, S_IRUGO | S_IWUSR);
> +static int printk_time = CONFIG_PRINTK_TIME;
> +static int printk_time_setting;
> +
> +/**
> + * enum printk_time_type - Timestamp types for printk() messages.
> + * @PRINTK_TIME_DISABLE: No time stamp.
> + * @PRINTK_TIME_LOCAL: Local hardware clock timestamp.
> + * @PRINTK_TIME_BOOT: Boottime clock timestamp.
> + * @PRINTK_TIME_MONO: Monotonic clock timestamp.
> + * @PRINTK_TIME_REAL: Realtime clock timestamp.  On 32-bit
> + * systems selecting the real clock printk timestamp may lead to unlikely
> + * situations where a timestamp is wrong because the real time offset is read
> + * without the protection of a sequence lock in the call to 
> ktime_get_log_ts()
> + * in printk_get_ts() below.

You can expand on this or the actual routines that use this in kdoc form.

> + */
> +enum printk_time_type {
> + PRINTK_TIME_DISABLE = 0,
> + PRINTK_TIME_LOCAL = 1,
> + PRINTK_TIME_BOOT = 2,
> + PRINTK_TIME_MONO = 3,
> + PRINTK_TIME_REAL = 4,
> +};
> +
> +static const char * const printk_time_str[5] = {
> + "disabled",
> + "local hardware",
> + "boottime",
> + "monotonic",
> + "realtime",
> +};
> +
> +static int printk_time_set(const char *val, const struct kernel_param *kp)
> +{
> + char *param = strstrip((char *)val);
> + int _printk_time;
> +
> + if (strlen(param) != 1)
> + return -EINVAL;
> +
> + switch (param[0]) {
> + case '0':
> + case 'n':
> + case 'N':
> + _printk_time = PRINTK_TIME_DISABLE;
> + break;
> + case '1':
> + case 'y':
> + case 'Y':
> + _printk_time = PRINTK_TIME_LOCAL;
> + break;
> + case '2':
> + _printk_time = PRINTK_TIME_BOOT;
> + break;
> + case '3':
> + _printk_time = PRINTK_TIME_MONO;
> + break;
> + case '4':
> + _printk_time = PRINTK_TIME_REAL;
> + break;
> + default:
> + pr_warn("printk: invalid timestamp value\n");
> + return -EINVAL;
> + }
> +
> + /*
> +  * Only allow enabling and disabling of the current printk_time
> +  * setting.  Changing it from one setting to another confuses
> +  * userspace.
> +  */
> + if (printk_time_setting == PRINTK_TIME_DISABLE) {
> + printk_time_setting = _printk_time;
> + } else if ((printk_time_setting != _printk_time) &&
> +(_printk_time != 0)) {
> + pr_warn("printk: timestamp can only be set to 0(disabled) or 
> %d(%s) ",
> + printk_time_setting,
> + printk_time_str[printk_time_setting]);
> + return -EINVAL;
> + }
> +
> + printk_time = _printk_time;
> + pr_info("printk: timestamp set to %d(%s).",
> + printk_time, printk_time_str[printk_time]);
> + return 0;
> +}
> +
> +static int printk_time_get(char *buffer, const struct kernel_param *kp)
> +{
> + return scnprintf(buffer, PAGE_SIZE, "%d", printk_time);
> +}
> +
> +static struct kernel_param_ops printk_time_ops = {
> + .set = printk_time_set,
> + .get = printk_time_get,
> +};
> +module_param_cb(time, _time_ops, NULL, 0644);
> +
> +static u64 printk_get_ts(void)
> +{
> + u64 mono, offset_real;
> +
> + if (printk_time <= PRINTK_TIME_LOCAL)
> + return local_clock();
> +
> + if (printk_time == PRINTK_TIME_BOOT)
> + return ktime_get_boot_log_ts();
> +
> + mono = ktime_get_real_log_ts(_real);
> +
> + if (printk_time == PRINTK_TIME_MONO)
> + return mono;
> +
> + return mono + offset_real;
> +}
>  
>  static size_t print_time(u64 ts, char *buf)
>  {
> @@ -1643,7 +1756,7 @@ static bool cont_add(int facility, int level, enum 
> log_flags flags, const char *
>   cont.facility = facility;
>   cont.level = level;
>   cont.owner = current;
> - cont.ts_nsec = local_clock();
> + cont.ts_nsec = printk_get_ts();
>   cont.flags = flags;
>   }
>  
> @@ -1873,6 +1986,8 @@ static size_t msg_print_text(const struct printk_log 
> *msg,
>bool syslog, char *buf, size_t size) { return 0; }
>  static bool suppress_message_printing(int level) { return false; }
>  
> +static int printk_time;
> +static int printk_time_setting;
>  #endif /* CONFIG_PRINTK */
>  
>  #ifdef CONFIG_EARLY_PRINTK
>
> @@ -2659,6 +2774,10 @@ static int __init printk_late_init(void)
>   struct console *con;
>   int ret;
>  
> + /* initialize printk_time settings */
> + if 

Re: [PATCH v4] printk: Add monotonic, boottime, and realtime timestamps

[Mark Salyzyn]

On 08/07/2017 08:52 AM, Prarit Bhargava wrote:

diff --git a/arch/arm/configs/aspeed_g4_defconfig 
b/arch/arm/configs/aspeed_g4_defconfig
index cfc2465e8b77..5f3c50914e92 100644
--- a/arch/arm/configs/aspeed_g4_defconfig
+++ b/arch/arm/configs/aspeed_g4_defconfig
@@ -162,7 +162,7 @@ CONFIG_JFFS2_FS_XATTR=y
  CONFIG_UBIFS_FS=y
  CONFIG_SQUASHFS=y
  CONFIG_SQUASHFS_XZ=y
-CONFIG_PRINTK_TIME=y
+CONFIG_PRINTK_TIME_LOCAL=y
  CONFIG_DYNAMIC_DEBUG=y
  CONFIG_STRIP_ASM_SYMS=y
  CONFIG_DEBUG_FS=y

Many have had misgivings, let me try another pass at this.

We (royal we) should really look into adjusting configuration parsing to 
allow an easy transition from boolean to selection ... I am sure this is 
not the first time bistate/tristate was moved to a number.


An idea? Maybe look into a way to deal with this to use something 
_other_ than CONFIG_PRINTK_TIME to hold the selection, and keep a 
(hidden/legacy?) CONFIG_PRINTK_TIME that when selected sets 
CONFIG_PRINTK_TIME_LOCAL, and switch to _not_ CONFIG_PRINTK_TIME_DISABLE 
as the internal mechanical replacement for it. I do not know how 
disruptive this will be, but is worth it if the codebase supports it, 
and legacy config retained?

+
+static int printk_time_set(const char *val, const struct kernel_param *kp)
+{
+   char *param = strstrip((char *)val);
+   int _printk_time = -1;
+   int stamp;
+
+   if (strlen(param) == 1) {
+   /* Preserve legacy boolean settings */
+   if (!strcmp("0", param) || !strcmp("n", param) ||

if strlen(param) == 1, then param[0] == '0' etc works fine and is KISS.

+   /*
+* Only allow enabling and disabling of the current printk_time
+* setting.  Changing it from one setting to another confuses
+* userspace.
+*/
+   if (printk_time_setting == PRINTK_TIME_DISABLE) {
+   printk_time_setting = _printk_time;
+   } else if ((printk_time_setting != _printk_time) &&
+  (_printk_time != 0)) {
+   pr_warn("printk: timestamp can only be set to 0(disabled) or 
%s\n",
+   printk_time_str[printk_time_setting]);
+   return -EINVAL;
+   }
I agree with the restriction in the general case.  However (as hinted at 
before() #ifdef CONFIG_PRINTK_TIME_RESTRICT (default y, or #ifndef 
CONFIG_PRINTK_TIME_DEBUG default n) around this will allow us users to 
choose if we are confused or not. I can see being able to change it on 
the fly as an option. Especially since we have 
/sys/module/printk/parameters/time.


-- Mark
--
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 v4] printk: Add monotonic, boottime, and realtime timestamps

[John Stultz]

On Mon, Aug 7, 2017 at 8:52 AM, Prarit Bhargava  wrote:
> printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock
> timestamp to printk messages.  The local hardware clock loses time each
> day making it difficult to determine exactly when an issue has occurred in
> the kernel log, and making it difficult to determine how kernel and
> hardware issues relate to each other in real time.
>
> Make printk output different timestampes by adding options for no
> timestamp, the local hardware clock, the monotonic clock, the boottime
> clock, and the real clock.  Allow a user to pick one of the clocks by
> using the printk.time kernel parameter.  Output the type of clock in
> /sys/module/printk/parameters/time so userspace programs can interpret the
> timestamp.
>
> Real clock & 32-bit systems:  Selecting the real clock printk timestamp may
> lead to unlikely situations where a timestamp is wrong because the real time
> offset is read without the protection of a sequence lock in the call to
> ktime_get_log_ts() in printk_get_ts().
>
> v2: Use peterz's suggested Kconfig options.  Merge patchset together.
> Fix i386 !CONFIG_PRINTK builds.
>
> v3: Fixed x86_64_defconfig. Added printk_time_type enum and
> printk_time_str for better output. Added BOOTTIME clock functionality.
>
> v4: Fix messages, add additional printk.time options, and fix configs.
>
> Signed-off-by: Prarit Bhargava 
> Cc: Mark Salyzyn 
> Cc: Jonathan Corbet 
> Cc: Petr Mladek 
> Cc: Sergey Senozhatsky 
> Cc: Steven Rostedt 
> Cc: John Stultz 
> Cc: Thomas Gleixner 
> Cc: Stephen Boyd 
> Cc: Andrew Morton 
> Cc: Greg Kroah-Hartman 
> Cc: "Paul E. McKenney" 
> Cc: Christoffer Dall 
> Cc: Deepa Dinamani 
> Cc: Ingo Molnar 
> Cc: Joel Fernandes 
> Cc: Prarit Bhargava 
> Cc: Kees Cook 
> Cc: Peter Zijlstra 
> Cc: Geert Uytterhoeven 
> Cc: "Luis R. Rodriguez" 
> Cc: Nicholas Piggin 
> Cc: "Jason A. Donenfeld" 
> Cc: Olof Johansson 
> Cc: Josh Poimboeuf 
> Cc: linux-doc@vger.kernel.org
> ---
>  Documentation/admin-guide/kernel-parameters.txt|   6 +-
>  arch/arm/configs/aspeed_g4_defconfig   |   2 +-
>  arch/arm/configs/aspeed_g5_defconfig   |   2 +-
>  arch/arm/configs/axm55xx_defconfig |   2 +-
>  arch/arm/configs/bcm2835_defconfig |   2 +-
>  arch/arm/configs/colibri_pxa270_defconfig  |   2 +-
>  arch/arm/configs/colibri_pxa300_defconfig  |   2 +-
>  arch/arm/configs/dove_defconfig|   2 +-
>  arch/arm/configs/efm32_defconfig   |   2 +-
>  arch/arm/configs/exynos_defconfig  |   2 +-
>  arch/arm/configs/ezx_defconfig |   2 +-
>  arch/arm/configs/h5000_defconfig   |   2 +-
>  arch/arm/configs/hisi_defconfig|   2 +-
>  arch/arm/configs/imote2_defconfig  |   2 +-
>  arch/arm/configs/imx_v6_v7_defconfig   |   2 +-
>  arch/arm/configs/keystone_defconfig|   2 +-
>  arch/arm/configs/lpc18xx_defconfig |   2 +-
>  arch/arm/configs/magician_defconfig|   2 +-
>  arch/arm/configs/mmp2_defconfig|   2 +-
>  arch/arm/configs/moxart_defconfig  |   2 +-
>  arch/arm/configs/mps2_defconfig|   2 +-
>  arch/arm/configs/multi_v7_defconfig|   2 +-
>  arch/arm/configs/mvebu_v7_defconfig|   2 +-
>  arch/arm/configs/mxs_defconfig |   2 +-
>  arch/arm/configs/omap2plus_defconfig   |   2 +-
>  arch/arm/configs/pxa168_defconfig  |   2 +-
>  arch/arm/configs/pxa3xx_defconfig  |   2 +-
>  arch/arm/configs/pxa910_defconfig  |   2 +-
>  arch/arm/configs/pxa_defconfig |   2 +-
>  arch/arm/configs/qcom_defconfig|   2 +-
>  arch/arm/configs/raumfeld_defconfig|   2 +-
>  arch/arm/configs/shmobile_defconfig|   2 +-
>  arch/arm/configs/socfpga_defconfig |   2 +-
>  arch/arm/configs/stm32_defconfig   |   2 +-
>  arch/arm/configs/sunxi_defconfig   |   2 +-
>  arch/arm/configs/tango4_defconfig  |   2 +-
>  arch/arm/configs/tegra_defconfig   |   2 +-
>  arch/arm/configs/u300_defconfig|   2 +-
>  arch/arm/configs/u8500_defconfig   |   2 

Re: NPTL docs inquiry

[Randy Dunlap]

On 08/07/2017 09:31 AM, Yubin Ruan wrote:
> Hi, I am wondering whether there is any progress for NPTL. In page[1]
> I see lots of pthread-related pages are missing. Pretty shocked by
> that.
> 
> Are there any plan for that? Who is the maintainer of NPTL? Why are
> such an important lib missing manual pages?
> 
> [1]: https://www.kernel.org/doc/man-pages/missing_pages.html

[adding Michael Kerrisk]

Wikipedia says:
{in https://en.wikipedia.org/wiki/Native_POSIX_Thread_Library}

"NPTL has been part of Red Hat Enterprise Linux since version 3, and in the 
Linux kernel since version 2.6. It is now a fully integrated part of the GNU C 
Library.[2]"

so I would expect the documentation to be part of that library.


-- 
~Randy
--
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

NPTL docs inquiry

[Yubin Ruan]

Hi, I am wondering whether there is any progress for NPTL. In page[1]
I see lots of pthread-related pages are missing. Pretty shocked by
that.

Are there any plan for that? Who is the maintainer of NPTL? Why are
such an important lib missing manual pages?

[1]: https://www.kernel.org/doc/man-pages/missing_pages.html

Yubin
--
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] printk: Add boottime and real timestamps

[Sergey Senozhatsky]

On (08/07/17 08:41), Prarit Bhargava wrote:
[..]
> >> +static int printk_time_set(const char *val, const struct kernel_param *kp)
> >> +{
> >> +char *param = strstrip((char *)val);
> >> +int _printk_time;
> >> +
> >> +if (strlen(param) != 1)
> >> +return -EINVAL;
> > (see below) strlen is so restrictive, wouldn't it be nice(tm) to allow 
> > "boot",
> > "monotonic" or "realtime" strings? Certainly KISS can handle the first 
> > letters
> > for next to zero cost. (switch statement optimization)
> 
> Thanks Mark,
> 
> I had asked this question before and didn't get an answer: Do I need to
> worry about the ABI of /sys/modules/printk/parameters/time.  Since it hasn't
> been explicitly added to the stable ABI files, I'm going to assume it wasn't
> important enough to add it.  Looking at google, however, leads to a lot
> of hits for 'printk.time' kernel parameters settings so I think I better
> maintain the legacy boolean settings.

yes, please. we have to preserve it.

> I'm going to do: 0/n/N/1/y/Y to maintain the existing ABI, and add (as you
> suggest above 'disable|local|boottime|monotonic|realtime' as valid
> parameters.
> 
> >> +
> >> +switch (param[0]) {
> >> +case '0':
> >> +case 'n':
> >> +case 'N':
> > I would wish for a few more 'convenience' cases:
> > 
> > case 'd': case 'D': /* Disable */
> 
> It would be trivial then to add only the lower case options (I dislike upper
> case settings ...) by adding

yes, please. lower case only.

-ss
--
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] pinctrl: generic: update references to Documentation/pinctrl.txt

[Linus Walleij]

On Sun, Aug 6, 2017 at 4:00 PM, Ludovic Desroches
 wrote:

> Update deprecated references to Documentation/pinctrl.txt since it has been
> moved to Documentation/driver-api/pinctl.rst.
>
> Signed-off-by: Ludovic Desroches 
> Fixes: 5a9b73832e9e ("pinctrl.txt: move it to the driver-api book")

Patch applied for fixes.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] doc: linux-wpan: Change the old function names to the lastest function names

[Stefan Schmidt]

Hello.

On 08/06/2017 06:28 PM, Jian-Hong Pan wrote:

The function declaration in the lastest include/net/mac802154.h has been
changed since v3.19.

ieee802154_alloc_device => ieee802154_alloc_hw
ieee802154_free_device => ieee802154_free_hw
ieee802154_register_device => ieee802154_register_hw
ieee802154_unregister_device => ieee802154_unregister_hw

However, the description in the Device drivers API section of
Documentation/networking/ieee802154.txt is still in the state of
v3.18.63.

Signed-off-by: Jian-Hong Pan 
---
  Documentation/networking/ieee802154.txt | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/Documentation/networking/ieee802154.txt 
b/Documentation/networking/ieee802154.txt
index 22bbc7225f8..ca1697a2273 100644
--- a/Documentation/networking/ieee802154.txt
+++ b/Documentation/networking/ieee802154.txt
@@ -96,17 +96,17 @@ Device drivers API
  ==
  
  The include/net/mac802154.h defines following functions:

- - struct ieee802154_dev *ieee802154_alloc_device
-   (size_t priv_size, struct ieee802154_ops *ops):
-   allocation of IEEE 802.15.4 compatible device
+ - struct ieee802154_hw *
+   ieee802154_alloc_hw(size_t priv_data_len, const struct ieee802154_ops *ops):
+   allocation of IEEE 802.15.4 compatible hardware device
  
- - void ieee802154_free_device(struct ieee802154_dev *dev):

-   freeing allocated device
+ - void ieee802154_free_hw(struct ieee802154_hw *hw):
+   freeing allocated hardware device
  
- - int ieee802154_register_device(struct ieee802154_dev *dev):

-   register PHY in the system
+ - int ieee802154_register_hw(struct ieee802154_hw *hw):
+   register PHY which is the allocated hardware device, in the system
  
- - void ieee802154_unregister_device(struct ieee802154_dev *dev):

+ - void ieee802154_unregister_hw(struct ieee802154_hw *hw):
 freeing registered PHY
  
  Moreover IEEE 802.15.4 device operations structure should be filled.




Acked-by: Stefan Schmidt 

Thanks for fixing this!

regards
Stefan Schmidt
--
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] printk: Add boottime and real timestamps

[Prarit Bhargava]

On 08/04/2017 11:36 AM, Mark Salyzyn wrote:
> On 08/03/2017 06:18 PM, Prarit Bhargava wrote:
> 
>> diff --git a/arch/arm/configs/aspeed_g4_defconfig
>> b/arch/arm/configs/aspeed_g4_defconfig
>> index cfc2465e8b77..6c73c305ad17 100644
>> --- a/arch/arm/configs/aspeed_g4_defconfig
>> +++ b/arch/arm/configs/aspeed_g4_defconfig
>> @@ -162,7 +162,9 @@ CONFIG_JFFS2_FS_XATTR=y
>>  CONFIG_UBIFS_FS=y
>>  CONFIG_SQUASHFS=y
>>  CONFIG_SQUASHFS_XZ=y
>> -CONFIG_PRINTK_TIME=y
>> +# CONFIG_PRINTK_TIME_DISABLE is not set
>> +CONFIG_PRINTK_TIME_LOCAL=Y
>> +CONFIG_PRINTK_TIME=1
>>  CONFIG_DYNAMIC_DEBUG=y
>>  CONFIG_STRIP_ASM_SYMS=y
>>  CONFIG_DEBUG_FS=y
> 
> savedefconfig tells me otherwise:
> 
> -CONFIG_PRINTK_TIME=y
> +CONFIG_PRINTK_TIME_LOCAL=y
> 
> is all that is needed, the rest is fluff and will cause a savedefconfig 
> mismatch
> error.
>> +static int printk_time_set(const char *val, const struct kernel_param *kp)
>> +{
>> +char *param = strstrip((char *)val);
>> +int _printk_time;
>> +
>> +if (strlen(param) != 1)
>> +return -EINVAL;
> (see below) strlen is so restrictive, wouldn't it be nice(tm) to allow "boot",
> "monotonic" or "realtime" strings? Certainly KISS can handle the first letters
> for next to zero cost. (switch statement optimization)

Thanks Mark,

I had asked this question before and didn't get an answer: Do I need to
worry about the ABI of /sys/modules/printk/parameters/time.  Since it hasn't
been explicitly added to the stable ABI files, I'm going to assume it wasn't
important enough to add it.  Looking at google, however, leads to a lot
of hits for 'printk.time' kernel parameters settings so I think I better
maintain the legacy boolean settings.

I'm going to do: 0/n/N/1/y/Y to maintain the existing ABI, and add (as you
suggest above 'disable|local|boottime|monotonic|realtime' as valid
parameters.

>> +
>> +switch (param[0]) {
>> +case '0':
>> +case 'n':
>> +case 'N':
> I would wish for a few more 'convenience' cases:
> 
> case 'd': case 'D': /* Disable */

It would be trivial then to add only the lower case options (I dislike upper
case settings ...) by adding

!strcmp(printk_time_str[0], param, 1)

P.
--
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 v4 0/6] Add HiSilicon SoC uncore Performance Monitoring Unit driver

[Zhangshaokun]

Hi Mark/Will,

Appreciate your comments.

Thanks.
Shaokun

On 2017/7/25 20:10, Shaokun Zhang wrote:
> This patchset adds support for HiSilicon SoC uncore PMUs driver. It
> includes L3C, Hydra Home Agent (HHA) and DDRC.
> 
> Changes in v4:
> * remove redundant code and comments
> * reverse the functions order in exit function
> * remove some GPL information
> * revise including header file
> * fix Jonathan's other comments
> 
> Changes in v3:
> * rebase to 4.13-rc1
> * add dev_err if ioremap fails for PMUs
>  
> Changes in v2:
> * fix kbuild test robot error
> * make hisi_uncore_ops static
> 
> Shaokun Zhang (6):
>   Documentation: perf: hisi: Documentation for HiSilicon SoC PMU driver
>   perf: hisi: Add support for HiSilicon SoC uncore PMU driver
>   perf: hisi: Add support for HiSilicon SoC L3C PMU driver
>   perf: hisi: Add support for HiSilicon SoC HHA PMU driver
>   perf: hisi: Add support for HiSilicon SoC DDRC PMU driver
>   arm64: MAINTAINERS: hisi: Add HiSilicon SoC PMU support
> 
>  Documentation/perf/hisi-pmu.txt   |  52 +++
>  MAINTAINERS   |   7 +
>  drivers/perf/Kconfig  |   7 +
>  drivers/perf/Makefile |   1 +
>  drivers/perf/hisilicon/Makefile   |   1 +
>  drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c | 420 
>  drivers/perf/hisilicon/hisi_uncore_hha_pmu.c  | 436 +
>  drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c  | 538 
> ++
>  drivers/perf/hisilicon/hisi_uncore_pmu.c  | 398 +++
>  drivers/perf/hisilicon/hisi_uncore_pmu.h  | 103 +
>  include/linux/cpuhotplug.h|   1 +
>  11 files changed, 1964 insertions(+)
>  create mode 100644 Documentation/perf/hisi-pmu.txt
>  create mode 100644 drivers/perf/hisilicon/Makefile
>  create mode 100644 drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c
>  create mode 100644 drivers/perf/hisilicon/hisi_uncore_hha_pmu.c
>  create mode 100644 drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c
>  create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.c
>  create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.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