Re: [PATCH v2 0/7] mm: pages for hugetlb's overcommit may be able to charge to memcg

[TSUKADA Koutaro]

On 2018/05/23 3:54, Michal Hocko wrote:
> On Tue 22-05-18 22:04:23, TSUKADA Koutaro wrote:
>> On 2018/05/22 3:07, Mike Kravetz wrote:
>>> On 05/17/2018 09:27 PM, TSUKADA Koutaro wrote:
 Thanks to Mike Kravetz for comment on the previous version patch.

 The purpose of this patch-set is to make it possible to control whether or
 not to charge surplus hugetlb pages obtained by overcommitting to memory
 cgroup. In the future, I am trying to accomplish limiting the memory usage
 of applications that use both normal pages and hugetlb pages by the memory
 cgroup(not use the hugetlb cgroup).

 Applications that use shared libraries like libhugetlbfs.so use both normal
 pages and hugetlb pages, but we do not know how much to use each. Please
 suppose you want to manage the memory usage of such applications by cgroup
 How do you set the memory cgroup and hugetlb cgroup limit when you want to
 limit memory usage to 10GB?

 If you set a limit of 10GB for each, the user can use a total of 20GB of
 memory and can not limit it well. Since it is difficult to estimate the
 ratio used by user of normal pages and hugetlb pages, setting limits of 2GB
 to memory cgroup and 8GB to hugetlb cgroup is not very good idea. In such a
 case, I thought that by using my patch-set, we could manage resources just
 by setting 10GB as the limit of memory cgoup(there is no limit to hugetlb
 cgroup).

 In this patch-set, introduce the charge_surplus_huge_pages(boolean) to
 struct hstate. If it is true, it charges to the memory cgroup to which the
 task that obtained surplus hugepages belongs. If it is false, do nothing as
 before, and the default value is false. The charge_surplus_huge_pages can
 be controlled procfs or sysfs interfaces.

 Since THP is very effective in environments with kernel page size of 4KB,
 such as x86, there is no reason to positively use HugeTLBfs, so I think
 that there is no situation to enable charge_surplus_huge_pages. However, in
 some distributions such as arm64, the page size of the kernel is 64KB, and
 the size of THP is too huge as 512MB, making it difficult to use. HugeTLBfs
 may support multiple huge page sizes, and in such a special environment
 there is a desire to use HugeTLBfs.
>>>
>>> One of the basic questions/concerns I have is accounting for surplus huge
>>> pages in the default memory resource controller.  The existing huegtlb
>>> resource controller already takes hugetlbfs huge pages into account,
>>> including surplus pages.  This series would allow surplus pages to be
>>> accounted for in the default  memory controller, or the hugetlb controller
>>> or both.
>>>
>>> I understand that current mechanisms do not meet the needs of the above
>>> use case.  The question is whether this is an appropriate way to approach
>>> the issue.
> 
> I do share your view Mike!
> 
>>> My cgroup experience and knowledge is extremely limited, but
>>> it does not appear that any other resource can be controlled by multiple
>>> controllers.  Therefore, I am concerned that this may be going against
>>> basic cgroup design philosophy.
>>
>> Thank you for your feedback.
>> That makes sense, surplus hugepages are charged to both memcg and hugetlb
>> cgroup, which may be contrary to cgroup design philosophy.
>>
>> Based on the above advice, I have considered the following improvements,
>> what do you think about?
>>
>> The 'charge_surplus_hugepages' of v2 patch-set was an option to switch
>> "whether to charge memcg in addition to hugetlb cgroup", but it will be
>> abolished. Instead, change to "switch only to memcg instead of hugetlb
>> cgroup" option. This is called 'surplus_charge_to_memcg'.
> 
> This all looks so hackish and ad-hoc that I would be tempted to give it
> an outright nack, but let's here more about why do we need this fiddling
> at all. I've asked in other email so I guess I will get an answer there
> but let me just emphasize again that I absolutely detest a possibility
> to put hugetlb pages into the memcg mix. They just do not belong there.
> Try to look at previous discussions why it has been decided to have a
> separate hugetlb pages at all.
> 
> I am also quite confused why you keep distinguishing surplus hugetlb
> pages from regular preallocated ones. Being a surplus page is an
> implementation detail that we use for an internal accounting rather than
> something to exhibit to the userspace even more than we do currently.

I apologize for having confused.

The hugetlb pages obtained from the pool do not waste the buddy pool. On
the other hand, surplus hugetlb pages waste the buddy pool. Due to this
difference in property, I thought it could be distinguished.

Although my memcg knowledge is extremely limited, memcg is accounting for
various kinds of pages obtained from the buddy pool by the task belonging
to it. I would like to argue that surplus hugepage has 

Re: [PATCH v2 0/7] mm: pages for hugetlb's overcommit may be able to charge to memcg

[TSUKADA Koutaro]

On 2018/05/22 22:51, Michal Hocko wrote:
> On Fri 18-05-18 13:27:27, TSUKADA Koutaro wrote:
>> The purpose of this patch-set is to make it possible to control whether or
>> not to charge surplus hugetlb pages obtained by overcommitting to memory
>> cgroup. In the future, I am trying to accomplish limiting the memory usage
>> of applications that use both normal pages and hugetlb pages by the memory
>> cgroup(not use the hugetlb cgroup).
> 
> There was a deliberate decision to keep hugetlb and "normal" memory
> cgroup controllers separate. Mostly because hugetlb memory is an
> artificial memory subsystem on its own and it doesn't fit into the rest
> of memcg accounted memory very well. I believe we want to keep that
> status quo.
> 
>> Applications that use shared libraries like libhugetlbfs.so use both normal
>> pages and hugetlb pages, but we do not know how much to use each. Please
>> suppose you want to manage the memory usage of such applications by cgroup
>> How do you set the memory cgroup and hugetlb cgroup limit when you want to
>> limit memory usage to 10GB?
> 
> Well such a usecase requires an explicit configuration already. Either
> by using special wrappers or modifying the code. So I would argue that
> you have quite a good knowlege of the setup. If you need a greater
> flexibility then just do not use hugetlb at all and rely on THP.
> [...]
> 
>> In this patch-set, introduce the charge_surplus_huge_pages(boolean) to
>> struct hstate. If it is true, it charges to the memory cgroup to which the
>> task that obtained surplus hugepages belongs. If it is false, do nothing as
>> before, and the default value is false. The charge_surplus_huge_pages can
>> be controlled procfs or sysfs interfaces.
> 
> I do not really think this is a good idea. We really do not want to make
> the current hugetlb code more complex than it is already. The current
> hugetlb cgroup controller is simple and works at least somehow. I would
> not add more on top unless there is a _really_ strong usecase behind.
> Please make sure to describe such a usecase in details before we even
> start considering the code.

Thank you for your time.

I do not know if it is really a strong use case, but I will explain my
motive in detail. English is not my native language, so please pardon
my poor English.

I am one of the developers for software that managing the resource used
from user job at HPC-Cluster with Linux. The resource is memory mainly.
The HPC-Cluster may be shared by multiple people and used. Therefore, the
memory used by each user must be strictly controlled, otherwise the
user's job will runaway, not only will it hamper the other users, it will
crash the entire system in OOM.

Some users of HPC are very nervous about performance. Jobs are executed
while synchronizing with MPI communication using multiple compute nodes.
Since CPU wait time will occur when synchronizing, they want to minimize
the variation in execution time at each node to reduce waiting times as
much as possible. We call this variation a noise.

THP does not guarantee to use the Huge Page, but may use the normal page.
This mechanism is one cause of variation(noise).

The users who know this mechanism will be hesitant to use THP. However,
the users also know the benefits of the Huge Page's TLB hit rate
performance, and the Huge Page seems to be attractive. It seems natural
that these users are interested in HugeTLBfs, I do not know at all
whether it is the right approach or not.

At the very least, our HPC system is pursuing high versatility and we
have to consider whether we can provide it if users want to use HugeTLBfs.

In order to use HugeTLBfs we need to create a persistent pool, but in
our use case sharing nodes, it would be impossible to create, delete or
resize the pool.

One of the answers I have reached is to use HugeTLBfs by overcommitting
without creating a pool(this is the surplus hugepage).

Surplus hugepages is hugetlb page, but I think at least that consuming
buddy pool is a decisive difference from hugetlb page of persistent pool.
If nr_overcommit_hugepages is assumed to be infinite, allocating pages for
surplus hugepages from buddy pool is all unlimited even if being limited
by memcg. In extreme cases, overcommitment will allow users to exhaust
the entire memory of the system. Of course, this can be prevented by the
hugetlb cgroup, but even if we set the limit for memcg and hugetlb cgroup
respectively, as I asked in the first mail(set limit to 10GB), the
control will not work.

I thought I could charge surplus hugepages to memcg, but maybe I did not
have enough knowledge about memcg. I would like to reply to another mail
for details.

>> Since THP is very effective in environments with kernel page size of 4KB,
>> such as x86, there is no reason to positively use HugeTLBfs, so I think
>> that there is no situation to enable charge_surplus_huge_pages. However, in
>> some distributions such as arm64, the page size of the kernel is 64KB, and

[PATCH RESEND] Documentation: filesystems: update filesystem locking documentation

[Sean Anderson]

Documentation/filesystems/Locking no longer reflects current locking
semantics. i_mutex is no longer used for locking, and has been superseded
by i_rwsem. Additionally, ->iterate_shared() was not documented.

Signed-off-by: Sean Anderson 
Reviewed-by: Jeff Layton 
---
 Documentation/filesystems/Locking | 43 +--
 1 file changed, 24 insertions(+), 19 deletions(-)

diff --git a/Documentation/filesystems/Locking 
b/Documentation/filesystems/Locking
index 75d2d57e2c44..15853d522941 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -69,31 +69,31 @@ prototypes:
 
 locking rules:
all may block
-   i_mutex(inode)
-lookup:yes
-create:yes
-link:  yes (both)
-mknod: yes
-symlink:   yes
-mkdir: yes
-unlink:yes (both)
-rmdir: yes (both)  (see below)
-rename:yes (all)   (see below)
+   i_rwsem(inode)
+lookup:shared
+create:exclusive
+link:  exclusive (both)
+mknod: exclusive
+symlink:   exclusive
+mkdir: exclusive
+unlink:exclusive (both)
+rmdir: exclusive (both)(see below)
+rename:exclusive (all) (see below)
 readlink:  no
 get_link:  no
-setattr:   yes
+setattr:   exclusive
 permission:no (may not block if called in rcu-walk mode)
 get_acl:   no
 getattr:   no
 listxattr: no
 fiemap:no
 update_time:   no
-atomic_open:   yes
+atomic_open:   exclusive
 tmpfile:   no
 
 
-   Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on
-victim.
+   Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_rwsem
+   exclusive on victim.
cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem.
 
 See Documentation/filesystems/directory-locking for more detailed discussion
@@ -111,10 +111,10 @@ prototypes:
 
 locking rules:
all may block
-   i_mutex(inode)
+   i_rwsem(inode)
 list:  no
 get:   no
-set:   yes
+set:   exclusive
 
 --- super_operations ---
 prototypes:
@@ -217,14 +217,14 @@ prototypes:
 locking rules:
All except set_page_dirty and freepage may block
 
-   PageLocked(page)i_mutex
+   PageLocked(page)i_rwsem
 writepage: yes, unlocks (see below)
 readpage:  yes, unlocks
 writepages:
 set_page_dirty no
 readpages:
-write_begin:   locks the page  yes
-write_end: yes, unlocksyes
+write_begin:   locks the page  exclusive
+write_end: yes, unlocksexclusive
 bmap:
 invalidatepage:yes
 releasepage:   yes
@@ -439,6 +439,7 @@ prototypes:
ssize_t (*read_iter) (struct kiocb *, struct iov_iter *);
ssize_t (*write_iter) (struct kiocb *, struct iov_iter *);
int (*iterate) (struct file *, struct dir_context *);
+   int (*iterate_shared) (struct file *, struct dir_context *);
unsigned int (*poll) (struct file *, struct poll_table_struct *);
long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
@@ -480,6 +481,10 @@ mutex or just to use i_size_read() instead.
 Note: this does not protect the file->f_pos against concurrent modifications
 since this is something the userspace has to take care about.
 
+->iterate() is called with i_rwsem exclusive.
+
+->iterate_shared() is called with i_rwsem at least shared.
+
 ->fasync() is responsible for maintaining the FASYNC bit in filp->f_flags.
 Most instances call fasync_helper(), which does that maintenance, so it's
 not normally something one needs to worry about.  Return values > 0 will be
-- 
2.17.0



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v6 4/5] arm64: dts: sdm845: Add serial console support

[Rajendra Nayak]

On 05/23/2018 08:43 PM, Doug Anderson wrote:
> Rajendra,
> 
> On Tue, May 22, 2018 at 11:30 PM, Rajendra Nayak  
> wrote:
>>
>>
>> On 03/30/2018 10:38 PM, Karthikeyan Ramasubramanian wrote:
>>> From: Rajendra Nayak 
>>>
>>> Add the qup uart node and geni se instance needed to
>>> support the serial console on the MTP.
>>>
>>> Signed-off-by: Rajendra Nayak 
>>> Signed-off-by: Karthikeyan Ramasubramanian 
>>> ---
>>
>> Andy, is it possible to pull this one in for 4.18?
>> Sorry, I only realized we somehow missed this after looking at your pull 
>> request.
>>
>> This is the only patch that prevents linux-next from booting up my sdm845 MTP
>> to a minimal console shell.
> 
> It was in Andy's tree but then got dropped.  Unfortunately the clock
> bindings didn't land early enough so it's a bit difficult to land any
> device tree changes that use the clock bindings until the next kernel
> revision...

ah, okay, did not realize that. Thanks for clarifying.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs: update kernel versions and dates in tables

[Jonathan Corbet]

On Wed, 23 May 2018 15:20:14 -0700
Tim Bird  wrote:

> Every once in a while, we should update the examples
> to reflect more recent kernel versions.
> 
> Update the tables describing kernel releases, the merge window,
> and current longterm maintained kernel, from 2.6-era kernels
> to 4.x.

I dunno...it's only been since 2011...aren't you being a little hasty?

:)

Applied, 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

[PATCH] docs: update kernel versions and dates in tables

[Tim Bird]

Every once in a while, we should update the examples
to reflect more recent kernel versions.

Update the tables describing kernel releases, the merge window,
and current longterm maintained kernel, from 2.6-era kernels
to 4.x.

Signed-off-by: Tim Bird 
---
 Documentation/process/2.Process.rst | 72 +++--
 1 file changed, 38 insertions(+), 34 deletions(-)

diff --git a/Documentation/process/2.Process.rst 
b/Documentation/process/2.Process.rst
index ce5561b..a9c46dd 100644
--- a/Documentation/process/2.Process.rst
+++ b/Documentation/process/2.Process.rst
@@ -18,17 +18,17 @@ major kernel release happening every two or three months.  
The recent
 release history looks like this:
 
==  =
-   2.6.38  March 14, 2011
-   2.6.37  January 4, 2011
-   2.6.36  October 20, 2010
-   2.6.35  August 1, 2010
-   2.6.34  May 15, 2010
-   2.6.33  February 24, 2010
+   4.11April 30, 2017
+   4.12July 2, 2017
+   4.13September 3, 2017
+   4.14November 12, 2017
+   4.15January 28, 2018
+   4.16April 1, 2018
==  =
 
-Every 2.6.x release is a major kernel release with new features, internal
-API changes, and more.  A typical 2.6 release can contain nearly 10,000
-changesets with changes to several hundred thousand lines of code.  2.6 is
+Every 4.x release is a major kernel release with new features, internal
+API changes, and more.  A typical 4.x release contain about 13,000
+changesets with changes to several hundred thousand lines of code.  4.x is
 thus the leading edge of Linux kernel development; the kernel uses a
 rolling development model which is continually integrating major changes.
 
@@ -70,20 +70,19 @@ will get up to somewhere between -rc6 and -rc9 before the 
kernel is
 considered to be sufficiently stable and the final 2.6.x release is made.
 At that point the whole process starts over again.
 
-As an example, here is how the 2.6.38 development cycle went (all dates in
-2011):
+As an example, here is how the 4.16 development cycle went (all dates in
+2018):
 
==  ===
-   January 4   2.6.37 stable release
-   January 18  2.6.38-rc1, merge window closes
-   January 21  2.6.38-rc2
-   February 1  2.6.38-rc3
-   February 7  2.6.38-rc4
-   February 15 2.6.38-rc5
-   February 21 2.6.38-rc6
-   March 1 2.6.38-rc7
-   March 7 2.6.38-rc8
-   March 142.6.38 stable release
+   January 28  4.15 stable release
+   February 11 4.16-rc1, merge window closes
+   February 18 4.16-rc2
+   February 25 4.16-rc3
+   March 4 4.16-rc4
+   March 114.16-rc5
+   March 184.16-rc6
+   March 254.16-rc7
+   April 1 4.17 stable release
==  ===
 
 How do the developers decide when to close the development cycle and create
@@ -99,37 +98,42 @@ release is made.  In the real world, this kind of 
perfection is hard to
 achieve; there are just too many variables in a project of this size.
 There comes a point where delaying the final release just makes the problem
 worse; the pile of changes waiting for the next merge window will grow
-larger, creating even more regressions the next time around.  So most 2.6.x
+larger, creating even more regressions the next time around.  So most 4.x
 kernels go out with a handful of known regressions though, hopefully, none
 of them are serious.
 
 Once a stable release is made, its ongoing maintenance is passed off to the
 "stable team," currently consisting of Greg Kroah-Hartman.  The stable team
-will release occasional updates to the stable release using the 2.6.x.y
+will release occasional updates to the stable release using the 4.x.y
 numbering scheme.  To be considered for an update release, a patch must (1)
 fix a significant bug, and (2) already be merged into the mainline for the
 next development kernel.  Kernels will typically receive stable updates for
 a little more than one development cycle past their initial release.  So,
-for example, the 2.6.36 kernel's history looked like:
+for example, the 4.13 kernel's history looked like:
 
==  ===
-   October 10  2.6.36 stable release
-   November 22 2.6.36.1
-   December 9  2.6.36.2
-   January 7   2.6.36.3
-   February 17 2.6.36.4
+   September 3 4.13 stable release
+   September 134.13.1
+   September 204.13.2
+   September 274.13.3
+   October 5   4.13.4
+   October 12  4.13.5
+   ... ...
+   November 24 4.13.16
==  ===
 
-2.6.36.4 was the final stable update for the 2.6.36 release.
+4.13.16 was the 

Re: [PATCH bpf-next v2 0/3] bpf: add boot parameters for sysctl knobs

[Alexei Starovoitov]

On Wed, May 23, 2018 at 02:18:19PM +0200, Eugene Syromiatnikov wrote:
> Some BPF sysctl knobs affect the loading of BPF programs, and during
> system boot/init stages these sysctls are not yet configured.
> A concrete example is systemd, that has implemented loading of BPF
> programs.
> 
> Thus, to allow controlling these setting at early boot, this patch set
> adds the ability to change the default setting of these sysctl knobs
> as well as option to override them via a boot-time kernel parameter
> (in order to avoid rebuilding kernel each time a need of changing these
> defaults arises).
> 
> The sysctl knobs in question are kernel.unprivileged_bpf_disable,
> net.core.bpf_jit_harden, and net.core.bpf_jit_kallsyms.

- systemd is root. today it only uses cgroup-bpf progs which require root,
  so disabling unpriv during boot time makes no difference to systemd.
  what is the actual reason to present time?

- say in the future systemd wants to use so_reuseport+bpf for faster
  networking. With unpriv disable during boot, it will force systemd
  to do such networking from root, which will lower its security barrier.
  How that make sense?

- bpf_jit_kallsyms sysctl has immediate effect on loaded programs.
  Flipping it during the boot or right after or any time after
  is the same thing. Why add such boot flag then?

- jit_harden can be turned on by systemd. so turning it during the boot
  will make systemd progs to be constant blinded.
  Constant blinding protects kernel from unprivileged JIT spraying.
  Are you worried that systemd will attack the kernel with JIT spraying?

--
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 v8 4/6] cpuset: Make generate_sched_domains() recognize isolated_cpus

[Waiman Long]

On 05/23/2018 01:34 PM, Patrick Bellasi wrote:
> Hi Waiman,
>
> On 17-May 16:55, Waiman Long wrote:
>
> [...]
>
>> @@ -672,13 +672,14 @@ static int generate_sched_domains(cpumask_var_t 
>> **domains,
>>  int ndoms = 0;  /* number of sched domains in result */
>>  int nslot;  /* next empty doms[] struct cpumask slot */
>>  struct cgroup_subsys_state *pos_css;
>> +bool root_load_balance = is_sched_load_balance(_cpuset);
>>  
>>  doms = NULL;
>>  dattr = NULL;
>>  csa = NULL;
>>  
>>  /* Special case for the 99% of systems with one, full, sched domain */
>> -if (is_sched_load_balance(_cpuset)) {
>> +if (root_load_balance && !top_cpuset.isolation_count) {
> Perhaps I'm missing something but, it seems to me that, when the two
> conditions above are true, then we are going to destroy and rebuild
> the exact same scheduling domains.
>
> IOW, on 99% of systems where:
>
>is_sched_load_balance(_cpuset)
>top_cpuset.isolation_count = 0
>
> since boot time and forever, then every time we update a value for
> cpuset.cpus we keep rebuilding the same SDs.
>
> It's not strictly related to this patch, the same already happens in
> mainline based just on the first condition, but since you are extending
> that optimization, perhaps you can tell me where I'm possibly wrong or
> which cases I'm not considering.
>
> I'm interested mainly because on Android systems those conditions
> are always true and we see SDs rebuilds every time we write
> something in cpuset.cpus, which ultimately accounts for almost all the
> 6-7[ms] time required for the write to return, depending on the CPU
> frequency.
>
> Cheers Patrick
>
Yes, that is true. I will look into how to further optimize this. Thanks
for the suggestion.

-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 RFC V2 2/6] hwmon: Add support for RPi voltage sensor

[Guenter Roeck]

On Wed, May 23, 2018 at 01:12:10PM +0100, Robin Murphy wrote:
> On 22/05/18 20:31, Stefan Wahren wrote:
> [...]
> >+static int rpi_hwmon_probe(struct platform_device *pdev)
> >+{
> >+struct device *dev = >dev;
> >+struct rpi_hwmon_data *data;
> >+int ret;
> >+
> >+data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> >+if (!data)
> >+return -ENOMEM;
> >+
> >+data->fw = 
> >platform_get_drvdata(to_platform_device(dev->parent));
> >+if (!data->fw)
> >+return -EPROBE_DEFER;
> >+
> 
> I am a bit at loss here (and sorry I didn't bring this up before).
> How would this ever be possible, given that the driver is registered
> from the firmware driver ?
> >>>
> >>>Do you refer to the (wrong) return code, the assumption that the parent 
> >>>must be a platform driver or a possible race?
> >>>
> >>
> >>The return code is one thing. My question was how the driver would ever be 
> >>instantiated
> >>with platform_get_drvdata(to_platform_device(dev->parent)) == NULL (but 
> >>dev->parent != NULL),
> >>so I referred to the race. But, sure, a second question would be how that 
> >>would indicate
> >>that the parent is not instantiated yet (which by itself seems like an odd 
> >>question).
> >
> >This shouldn't happen and worth a log error. In patch #3 the registration is 
> >called after the complete private data of the firmware driver is 
> >initialized. Did i missed something?
> >
> >But i must confess that i didn't test all builtin/module combinations.
> 
> The point is that, by construction, a "raspberrypi-hwmon" device will only
> ever be created for this driver to bind to if the firmware device is both
> fully initialised and known to support the GET_THROTTLED call already. Thus
> trying to check those again from the hwmon driver is at best pointless, and
> at worst misleading. If somebody *does* manage to bind this driver to some
> random inappropriate device, you've still got no guarantee that dev->parent
> is valid or that dev_get_drvdata(dev->parent)) won't return something
> non-NULL that isn't a struct rpi_firmware pointer, at which point you're
> liable to pass the paranoid check yet still crash anyway.
> 
> IOW, you can't reasonably defend against incorrect operation, and under
> correct operation there's nothing to defend against, so either way it's
> pretty futile to waste effort trying.
> 

Well said.

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

[PATCH v2 0/5] Expose PCIe AER stats via sysfs

[Rajat Jain]

This patchset exposes the AER stats via the sysfs attributes.

Patchset v2 has minor changes to v1 based on the review comments,
no functional change.
Primarily:
 * Fix license header
 * Use tabs instead of spaces
 * Remove use on unlikely() etc
 * Move documentation to Documentation/ABI/

Rajat Jain (5):
  PCI/AER: Define and allocate aer_stats structure for AER capable
devices
  PCI/AER: Add sysfs stats for AER capable devices
  PCI/AER: Add sysfs attributes to provide breakdown of AERs
  PCI/AER: Add sysfs attributes for rootport cumulative stats
  Documentation/ABI: Add details of PCI AER statistics

 .../testing/sysfs-bus-pci-devices-aer_stats   | 103 ++
 Documentation/PCI/pcieaer-howto.txt   |   5 +
 drivers/pci/pci-sysfs.c   |   3 +
 drivers/pci/pci.h |   4 +-
 drivers/pci/pcie/aer/Makefile |   2 +-
 drivers/pci/pcie/aer/aerdrv.h |  15 ++
 drivers/pci/pcie/aer/aerdrv_core.c|  11 +
 drivers/pci/pcie/aer/aerdrv_errprint.c|   7 +-
 drivers/pci/pcie/aer/aerdrv_stats.c   | 192 ++
 drivers/pci/probe.c   |   1 +
 include/linux/pci.h   |   3 +
 11 files changed, 342 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats
 create mode 100644 drivers/pci/pcie/aer/aerdrv_stats.c

-- 
2.17.0.441.gb46fe60e1d-goog

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

[PATCH v2 4/5] PCI/AER: Add sysfs attributes for rootport cumulative stats

[Rajat Jain]

Add sysfs attributes for rootport statistics (that are cumulative
of all the ERR_* messages seen on this PCI hierarchy).

Signed-off-by: Rajat Jain 
---
v2: same as v1

 drivers/pci/pcie/aer/aerdrv.h   |  2 ++
 drivers/pci/pcie/aer/aerdrv_core.c  |  2 ++
 drivers/pci/pcie/aer/aerdrv_stats.c | 31 +
 3 files changed, 35 insertions(+)

diff --git a/drivers/pci/pcie/aer/aerdrv.h b/drivers/pci/pcie/aer/aerdrv.h
index 048fbd7c9633..77d831d9 100644
--- a/drivers/pci/pcie/aer/aerdrv.h
+++ b/drivers/pci/pcie/aer/aerdrv.h
@@ -88,6 +88,8 @@ irqreturn_t aer_irq(int irq, void *context);
 int pci_aer_stats_init(struct pci_dev *pdev);
 void pci_aer_stats_exit(struct pci_dev *pdev);
 void pci_dev_aer_stats_incr(struct pci_dev *pdev, struct aer_err_info *info);
+void pci_rootport_aer_stats_incr(struct pci_dev *pdev,
+struct aer_err_source *e_src);
 
 extern const char
 *aer_correctable_error_string[AER_MAX_TYPEOF_CORRECTABLE_ERRS];
diff --git a/drivers/pci/pcie/aer/aerdrv_core.c 
b/drivers/pci/pcie/aer/aerdrv_core.c
index 42a6f913069a..0f70e22563f3 100644
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -424,6 +424,8 @@ static void aer_isr_one_error(struct pcie_device *p_device,
struct aer_rpc *rpc = get_service_data(p_device);
struct aer_err_info *e_info = >e_info;
 
+   pci_rootport_aer_stats_incr(p_device->port, e_src);
+
/*
 * There is a possibility that both correctable error and
 * uncorrectable error being logged. Report correctable error first.
diff --git a/drivers/pci/pcie/aer/aerdrv_stats.c 
b/drivers/pci/pcie/aer/aerdrv_stats.c
index e47321b267f6..898c9bc02ec2 100644
--- a/drivers/pci/pcie/aer/aerdrv_stats.c
+++ b/drivers/pci/pcie/aer/aerdrv_stats.c
@@ -57,6 +57,9 @@ static DEVICE_ATTR_RO(field)
 aer_stats_aggregate_attr(dev_total_cor_errs);
 aer_stats_aggregate_attr(dev_total_fatal_errs);
 aer_stats_aggregate_attr(dev_total_nonfatal_errs);
+aer_stats_aggregate_attr(rootport_total_cor_errs);
+aer_stats_aggregate_attr(rootport_total_fatal_errs);
+aer_stats_aggregate_attr(rootport_total_nonfatal_errs);
 
 #define aer_stats_breakdown_attr(field, stats_array, strings_array)\
static ssize_t  \
@@ -90,6 +93,9 @@ static struct attribute *aer_stats_attrs[] __ro_after_init = {
_attr_dev_total_nonfatal_errs.attr,
_attr_dev_breakdown_correctable.attr,
_attr_dev_breakdown_uncorrectable.attr,
+   _attr_rootport_total_cor_errs.attr,
+   _attr_rootport_total_fatal_errs.attr,
+   _attr_rootport_total_nonfatal_errs.attr,
NULL
 };
 
@@ -102,6 +108,12 @@ static umode_t aer_stats_attrs_are_visible(struct kobject 
*kobj,
if (!pdev->aer_stats)
return 0;
 
+   if ((a == _attr_rootport_total_cor_errs.attr ||
+a == _attr_rootport_total_fatal_errs.attr ||
+a == _attr_rootport_total_nonfatal_errs.attr) &&
+   pci_pcie_type(pdev) != PCI_EXP_TYPE_ROOT_PORT)
+   return 0;
+
return a->mode;
 }
 
@@ -144,6 +156,25 @@ void pci_dev_aer_stats_incr(struct pci_dev *pdev, struct 
aer_err_info *info)
counter[i]++;
 }
 
+void pci_rootport_aer_stats_incr(struct pci_dev *pdev,
+struct aer_err_source *e_src)
+{
+   struct aer_stats *aer_stats = pdev->aer_stats;
+
+   if (!aer_stats)
+   return;
+
+   if (e_src->status & PCI_ERR_ROOT_COR_RCV)
+   aer_stats->rootport_total_cor_errs++;
+
+   if (e_src->status & PCI_ERR_ROOT_UNCOR_RCV) {
+   if (e_src->status & PCI_ERR_ROOT_FATAL_RCV)
+   aer_stats->rootport_total_fatal_errs++;
+   else
+   aer_stats->rootport_total_nonfatal_errs++;
+   }
+}
+
 int pci_aer_stats_init(struct pci_dev *pdev)
 {
pdev->aer_stats = kzalloc(sizeof(struct aer_stats), GFP_KERNEL);
-- 
2.17.0.441.gb46fe60e1d-goog

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

[PATCH v2 1/5] PCI/AER: Define and allocate aer_stats structure for AER capable devices

[Rajat Jain]

Define a structure to hold the AER statistics. There are 2 groups
of statistics: dev_* counters that are to be collected for all AER
capable devices and rootport_* counters that are collected for all
(AER capable) rootports only. Allocate and free this structure when
device is added or released (thus counters survive the lifetime of the
device).

Add a new file aerdrv_stats.c to hold the AER stats collection logic.

Signed-off-by: Rajat Jain 
---
v2: Fix the license header as per Greg's suggestions
(Since there is disagreement with using "//" vs "/* */" for license
 I decided to keep the one preferred by Linus, also used by others
 in this directory)

 drivers/pci/pcie/aer/Makefile   |  2 +-
 drivers/pci/pcie/aer/aerdrv.h   |  6 +++
 drivers/pci/pcie/aer/aerdrv_core.c  |  9 +
 drivers/pci/pcie/aer/aerdrv_stats.c | 61 +
 drivers/pci/probe.c |  1 +
 include/linux/pci.h |  3 ++
 6 files changed, 81 insertions(+), 1 deletion(-)
 create mode 100644 drivers/pci/pcie/aer/aerdrv_stats.c

diff --git a/drivers/pci/pcie/aer/Makefile b/drivers/pci/pcie/aer/Makefile
index 09bd890875a3..a06f9cc2bde5 100644
--- a/drivers/pci/pcie/aer/Makefile
+++ b/drivers/pci/pcie/aer/Makefile
@@ -7,7 +7,7 @@ obj-$(CONFIG_PCIEAER) += aerdriver.o
 
 obj-$(CONFIG_PCIE_ECRC)+= ecrc.o
 
-aerdriver-objs := aerdrv_errprint.o aerdrv_core.o aerdrv.o
+aerdriver-objs := aerdrv_errprint.o aerdrv_core.o aerdrv.o aerdrv_stats.o
 aerdriver-$(CONFIG_ACPI) += aerdrv_acpi.o
 
 obj-$(CONFIG_PCIEAER_INJECT) += aer_inject.o
diff --git a/drivers/pci/pcie/aer/aerdrv.h b/drivers/pci/pcie/aer/aerdrv.h
index b4c950683cc7..d8b9fba536ed 100644
--- a/drivers/pci/pcie/aer/aerdrv.h
+++ b/drivers/pci/pcie/aer/aerdrv.h
@@ -33,6 +33,10 @@
PCI_ERR_UNC_MALF_TLP)
 
 #define AER_MAX_MULTI_ERR_DEVICES  5   /* Not likely to have more */
+
+#define AER_MAX_TYPEOF_CORRECTABLE_ERRS 16 /* as per PCI_ERR_COR_STATUS */
+#define AER_MAX_TYPEOF_UNCORRECTABLE_ERRS 26   /* as per PCI_ERR_UNCOR_STATUS*/
+
 struct aer_err_info {
struct pci_dev *dev[AER_MAX_MULTI_ERR_DEVICES];
int error_dev_num;
@@ -81,6 +85,8 @@ void aer_isr(struct work_struct *work);
 void aer_print_error(struct pci_dev *dev, struct aer_err_info *info);
 void aer_print_port_info(struct pci_dev *dev, struct aer_err_info *info);
 irqreturn_t aer_irq(int irq, void *context);
+int pci_aer_stats_init(struct pci_dev *pdev);
+void pci_aer_stats_exit(struct pci_dev *pdev);
 
 #ifdef CONFIG_ACPI_APEI
 int pcie_aer_get_firmware_first(struct pci_dev *pci_dev);
diff --git a/drivers/pci/pcie/aer/aerdrv_core.c 
b/drivers/pci/pcie/aer/aerdrv_core.c
index 36e622d35c48..42a6f913069a 100644
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -95,9 +95,18 @@ int pci_cleanup_aer_error_status_regs(struct pci_dev *dev)
 int pci_aer_init(struct pci_dev *dev)
 {
dev->aer_cap = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ERR);
+
+   if (!dev->aer_cap || pci_aer_stats_init(dev))
+   return -EIO;
+
return pci_cleanup_aer_error_status_regs(dev);
 }
 
+void pci_aer_exit(struct pci_dev *dev)
+{
+   pci_aer_stats_exit(dev);
+}
+
 /**
  * add_error_device - list device to be handled
  * @e_info: pointer to error info
diff --git a/drivers/pci/pcie/aer/aerdrv_stats.c 
b/drivers/pci/pcie/aer/aerdrv_stats.c
new file mode 100644
index ..2f48d6bc81f1
--- /dev/null
+++ b/drivers/pci/pcie/aer/aerdrv_stats.c
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Google Inc, All Rights Reserved.
+ *
+ * Rajat Jain (raja...@google.com)
+ *
+ * AER Statistics - exposed to userspace via /sysfs attributes.
+ */
+
+#include 
+#include "aerdrv.h"
+
+/* AER stats for the device */
+struct aer_stats {
+
+   /*
+* Fields for all AER capable devices. They indicate the errors
+* "as seen by this device". Note that this may mean that if an
+* end point is causing problems, the AER counters may increment
+* at its link partner (e.g. root port) because the errors will be
+* "seen" by the link partner and not the the problematic end point
+* itself (which may report all counters as 0 as it never saw any
+* problems).
+*/
+   /* Individual counters for different type of correctable errors */
+   u64 dev_cor_errs[AER_MAX_TYPEOF_CORRECTABLE_ERRS];
+   /* Individual counters for different type of uncorrectable errors */
+   u64 dev_uncor_errs[AER_MAX_TYPEOF_UNCORRECTABLE_ERRS];
+   /* Total number of correctable errors seen by this device */
+   u64 dev_total_cor_errs;
+   /* Total number of fatal uncorrectable errors seen by this device */
+   u64 dev_total_fatal_errs;
+   /* Total number of fatal uncorrectable errors seen by this device */
+   u64 dev_total_nonfatal_errs;
+
+   /*
+   

[PATCH v2 3/5] PCI/AER: Add sysfs attributes to provide breakdown of AERs

[Rajat Jain]

Add sysfs attributes to provide breakdown of the AERs seen,
into different type of correctable or uncorrectable errors:

dev_breakdown_correctable
dev_breakdown_uncorrectable

Signed-off-by: Rajat Jain 
---
v2: Use tabs instead of spaces, fix the subject, and print
all non zero counters.

 drivers/pci/pcie/aer/aerdrv.h  |  6 ++
 drivers/pci/pcie/aer/aerdrv_errprint.c |  6 --
 drivers/pci/pcie/aer/aerdrv_stats.c| 28 ++
 3 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pcie/aer/aerdrv.h b/drivers/pci/pcie/aer/aerdrv.h
index b5d5ad6f2c03..048fbd7c9633 100644
--- a/drivers/pci/pcie/aer/aerdrv.h
+++ b/drivers/pci/pcie/aer/aerdrv.h
@@ -89,6 +89,12 @@ int pci_aer_stats_init(struct pci_dev *pdev);
 void pci_aer_stats_exit(struct pci_dev *pdev);
 void pci_dev_aer_stats_incr(struct pci_dev *pdev, struct aer_err_info *info);
 
+extern const char
+*aer_correctable_error_string[AER_MAX_TYPEOF_CORRECTABLE_ERRS];
+
+extern const char
+*aer_uncorrectable_error_string[AER_MAX_TYPEOF_UNCORRECTABLE_ERRS];
+
 #ifdef CONFIG_ACPI_APEI
 int pcie_aer_get_firmware_first(struct pci_dev *pci_dev);
 #else
diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c 
b/drivers/pci/pcie/aer/aerdrv_errprint.c
index 5e8b98deda08..5585f309f1a8 100644
--- a/drivers/pci/pcie/aer/aerdrv_errprint.c
+++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
@@ -68,7 +68,8 @@ static const char *aer_error_layer[] = {
"Transaction Layer"
 };
 
-static const char *aer_correctable_error_string[] = {
+const char
+*aer_correctable_error_string[AER_MAX_TYPEOF_CORRECTABLE_ERRS] = {
"Receiver Error",   /* Bit Position 0   */
NULL,
NULL,
@@ -87,7 +88,8 @@ static const char *aer_correctable_error_string[] = {
"Header Log Overflow",  /* Bit Position 15  */
 };
 
-static const char *aer_uncorrectable_error_string[] = {
+const char
+*aer_uncorrectable_error_string[AER_MAX_TYPEOF_UNCORRECTABLE_ERRS] = {
"Undefined",/* Bit Position 0   */
NULL,
NULL,
diff --git a/drivers/pci/pcie/aer/aerdrv_stats.c 
b/drivers/pci/pcie/aer/aerdrv_stats.c
index beffef2b..e47321b267f6 100644
--- a/drivers/pci/pcie/aer/aerdrv_stats.c
+++ b/drivers/pci/pcie/aer/aerdrv_stats.c
@@ -58,10 +58,38 @@ aer_stats_aggregate_attr(dev_total_cor_errs);
 aer_stats_aggregate_attr(dev_total_fatal_errs);
 aer_stats_aggregate_attr(dev_total_nonfatal_errs);
 
+#define aer_stats_breakdown_attr(field, stats_array, strings_array)\
+   static ssize_t  \
+   field##_show(struct device *dev, struct device_attribute *attr, \
+char *buf) \
+{  \
+   unsigned int i; \
+   char *str = buf;\
+   struct pci_dev *pdev = to_pci_dev(dev); \
+   u64 *stats = pdev->aer_stats->stats_array;  \
+   for (i = 0; i < ARRAY_SIZE(strings_array); i++) {   \
+   if (strings_array[i])   \
+   str += sprintf(str, "%s = 0x%llx\n",\
+  strings_array[i], stats[i]); \
+   else if (stats[i])  \
+   str += sprintf(str, #stats_array "bit[%d] = 0x%llx\n",\
+  i, stats[i]);\
+   }   \
+   return str-buf; \
+}  \
+static DEVICE_ATTR_RO(field)
+
+aer_stats_breakdown_attr(dev_breakdown_correctable, dev_cor_errs,
+aer_correctable_error_string);
+aer_stats_breakdown_attr(dev_breakdown_uncorrectable, dev_uncor_errs,
+aer_uncorrectable_error_string);
+
 static struct attribute *aer_stats_attrs[] __ro_after_init = {
_attr_dev_total_cor_errs.attr,
_attr_dev_total_fatal_errs.attr,
_attr_dev_total_nonfatal_errs.attr,
+   _attr_dev_breakdown_correctable.attr,
+   _attr_dev_breakdown_uncorrectable.attr,
NULL
 };
 
-- 
2.17.0.441.gb46fe60e1d-goog

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

[PATCH v2 5/5] Documentation/ABI: Add details of PCI AER statistics

[Rajat Jain]

Add the PCI AER statistics details to
Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats
and provide a pointer to it in
Documentation/PCI/pcieaer-howto.txt

Signed-off-by: Rajat Jain 
---
v2: Move the documentation to Documentation/ABI/

 .../testing/sysfs-bus-pci-devices-aer_stats   | 103 ++
 Documentation/PCI/pcieaer-howto.txt   |   5 +
 2 files changed, 108 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats

diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats 
b/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats
new file mode 100644
index ..f55c389290ac
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats
@@ -0,0 +1,103 @@
+==
+PCIe Device AER statistics
+==
+These attributes show up under all the devices that are AER capable. These
+statistical counters indicate the errors "as seen/reported by the device".
+Note that this may mean that if an end point is causing problems, the AER
+counters may increment at its link partner (e.g. root port) because the
+errors will be "seen" / reported by the link partner and not the the
+problematic end point itself (which may report all counters as 0 as it never
+saw any problems).
+
+Where: /sys/bus/pci/devices//aer_stats/dev_total_cor_errs
+Date:  May 2018
+Kernel Version: 4.17.0
+Contact:   linux-...@vger.kernel.org, raja...@google.com
+Description:   Total number of correctable errors seen and reported by this
+   PCI device using ERR_COR.
+
+Where: /sys/bus/pci/devices//aer_stats/dev_total_fatal_errs
+Date:  May 2018
+Kernel Version: 4.17.0
+Contact:   linux-...@vger.kernel.org, raja...@google.com
+Description:   Total number of uncorrectable fatal errors seen and reported
+   by this PCI device using ERR_FATAL.
+
+Where: /sys/bus/pci/devices//aer_stats/dev_total_nonfatal_errs
+Date:  May 2018
+Kernel Version: 4.17.0
+Contact:   linux-...@vger.kernel.org, raja...@google.com
+Description:   Total number of uncorrectable non-fatal errors seen and reported
+   by this PCI device using ERR_NONFATAL.
+
+Where: /sys/bus/pci/devices//aer_stats/dev_breakdown_correctable
+Date:  May 2018
+Kernel Version: 4.17.0
+Contact:   linux-...@vger.kernel.org, raja...@google.com
+Description:   Breakdown of of correctable errors seen and reported by this
+   PCI device using ERR_COR. A sample result looks like this:
+-
+Receiver Error = 0x174
+Bad TLP = 0x19
+Bad DLLP = 0x3
+RELAY_NUM Rollover = 0x0
+Replay Timer Timeout = 0x1
+Advisory Non-Fatal = 0x0
+Corrected Internal Error = 0x0
+Header Log Overflow = 0x0
+-
+
+Where: /sys/bus/pci/devices//aer_stats/dev_breakdown_uncorrectable
+Date:  May 2018
+Kernel Version: 4.17.0
+Contact:   linux-...@vger.kernel.org, raja...@google.com
+Description:   Breakdown of of correctable errors seen and reported by this
+   PCI device using ERR_FATAL or ERR_NONFATAL. A sample result
+   looks like this:
+-
+Undefined = 0x0
+Data Link Protocol = 0x0
+Surprise Down Error = 0x0
+Poisoned TLP = 0x0
+Flow Control Protocol = 0x0
+Completion Timeout = 0x0
+Completer Abort = 0x0
+Unexpected Completion = 0x0
+Receiver Overflow = 0x0
+Malformed TLP = 0x0
+ECRC = 0x0
+Unsupported Request = 0x0
+ACS Violation = 0x0
+Uncorrectable Internal Error = 0x0
+MC Blocked TLP = 0x0
+AtomicOp Egress Blocked = 0x0
+TLP Prefix Blocked Error = 0x0
+-
+
+
+PCIe Rootport AER statistics
+
+These attributes showup under only the rootports that are AER capable. These
+indicate the number of error messages as "reported to" the rootport. Please 
note
+that the rootports also transmit (internally) the ERR_* messages for errors 
seen
+by the internal rootport PCI device, so these counters includes them and are
+thus cumulative of all the error messages on the PCI hierarchy originating
+at that root port.
+
+Where: /sys/bus/pci/devices//aer_stats/rootport_total_cor_errs
+Date:  May 2018
+Kernel Version: 4.17.0
+Contact:   linux-...@vger.kernel.org, raja...@google.com
+Description:   Total number of ERR_COR messages reported to rootport.
+
+Where: /sys/bus/pci/devices//aer_stats/rootport_total_fatal_errs
+Date:  May 2018
+Kernel Version: 4.17.0
+Contact:   linux-...@vger.kernel.org, raja...@google.com
+Description:   Total number of ERR_FATAL messages reported to rootport.
+
+Where: /sys/bus/pci/devices//aer_stats/rootport_total_nonfatal_errs
+Date:  May 2018
+Kernel Version: 4.17.0
+Contact:   linux-...@vger.kernel.org, raja...@google.com

[PATCH v2 2/5] PCI/AER: Add sysfs stats for AER capable devices

[Rajat Jain]

Add the following AER sysfs stats to represent the counters for each
kind of error as seen by the device:

dev_total_cor_errs
dev_total_fatal_errs
dev_total_nonfatal_errs

Signed-off-by: Rajat Jain 
---
v2: Use tabs instead of spaces at the end of macro lines, and remove
the use of unlikely() as per Greg's suggestion.

 drivers/pci/pci-sysfs.c|  3 ++
 drivers/pci/pci.h  |  4 +-
 drivers/pci/pcie/aer/aerdrv.h  |  1 +
 drivers/pci/pcie/aer/aerdrv_errprint.c |  1 +
 drivers/pci/pcie/aer/aerdrv_stats.c| 72 ++
 5 files changed, 80 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 366d93af051d..730f985a3dc9 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1743,6 +1743,9 @@ static const struct attribute_group 
*pci_dev_attr_groups[] = {
 #endif
_bridge_attr_group,
_dev_attr_group,
+#ifdef CONFIG_PCIEAER
+   _stats_attr_group,
+#endif
NULL,
 };
 
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index c358e7a07f3f..9a28ec600225 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -181,7 +181,9 @@ extern const struct attribute_group *pci_dev_groups[];
 extern const struct attribute_group *pcibus_groups[];
 extern const struct device_type pci_dev_type;
 extern const struct attribute_group *pci_bus_groups[];
-
+#ifdef CONFIG_PCIEAER
+extern const struct attribute_group aer_stats_attr_group;
+#endif
 
 /**
  * pci_match_one_device - Tell if a PCI device structure has a matching
diff --git a/drivers/pci/pcie/aer/aerdrv.h b/drivers/pci/pcie/aer/aerdrv.h
index d8b9fba536ed..b5d5ad6f2c03 100644
--- a/drivers/pci/pcie/aer/aerdrv.h
+++ b/drivers/pci/pcie/aer/aerdrv.h
@@ -87,6 +87,7 @@ void aer_print_port_info(struct pci_dev *dev, struct 
aer_err_info *info);
 irqreturn_t aer_irq(int irq, void *context);
 int pci_aer_stats_init(struct pci_dev *pdev);
 void pci_aer_stats_exit(struct pci_dev *pdev);
+void pci_dev_aer_stats_incr(struct pci_dev *pdev, struct aer_err_info *info);
 
 #ifdef CONFIG_ACPI_APEI
 int pcie_aer_get_firmware_first(struct pci_dev *pci_dev);
diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c 
b/drivers/pci/pcie/aer/aerdrv_errprint.c
index 21ca5e1b0ded..5e8b98deda08 100644
--- a/drivers/pci/pcie/aer/aerdrv_errprint.c
+++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
@@ -155,6 +155,7 @@ static void __aer_print_error(struct pci_dev *dev,
pci_err(dev, "   [%2d] Unknown Error Bit%s\n",
i, info->first_error == i ? " (First)" : "");
}
+   pci_dev_aer_stats_incr(dev, info);
 }
 
 void aer_print_error(struct pci_dev *dev, struct aer_err_info *info)
diff --git a/drivers/pci/pcie/aer/aerdrv_stats.c 
b/drivers/pci/pcie/aer/aerdrv_stats.c
index 2f48d6bc81f1..beffef2b 100644
--- a/drivers/pci/pcie/aer/aerdrv_stats.c
+++ b/drivers/pci/pcie/aer/aerdrv_stats.c
@@ -44,6 +44,78 @@ struct aer_stats {
u64 rootport_total_nonfatal_errs;
 };
 
+#define aer_stats_aggregate_attr(field)
\
+   static ssize_t  \
+   field##_show(struct device *dev, struct device_attribute *attr, \
+char *buf) \
+{  \
+   struct pci_dev *pdev = to_pci_dev(dev); \
+   return sprintf(buf, "0x%llx\n", pdev->aer_stats->field);\
+}  \
+static DEVICE_ATTR_RO(field)
+
+aer_stats_aggregate_attr(dev_total_cor_errs);
+aer_stats_aggregate_attr(dev_total_fatal_errs);
+aer_stats_aggregate_attr(dev_total_nonfatal_errs);
+
+static struct attribute *aer_stats_attrs[] __ro_after_init = {
+   _attr_dev_total_cor_errs.attr,
+   _attr_dev_total_fatal_errs.attr,
+   _attr_dev_total_nonfatal_errs.attr,
+   NULL
+};
+
+static umode_t aer_stats_attrs_are_visible(struct kobject *kobj,
+  struct attribute *a, int n)
+{
+   struct device *dev = kobj_to_dev(kobj);
+   struct pci_dev *pdev = to_pci_dev(dev);
+
+   if (!pdev->aer_stats)
+   return 0;
+
+   return a->mode;
+}
+
+const struct attribute_group aer_stats_attr_group = {
+   .name  = "aer_stats",
+   .attrs  = aer_stats_attrs,
+   .is_visible = aer_stats_attrs_are_visible,
+};
+
+void pci_dev_aer_stats_incr(struct pci_dev *pdev, struct aer_err_info *info)
+{
+   int status, i, max = -1;
+   u64 *counter = NULL;
+   struct aer_stats *aer_stats = pdev->aer_stats;
+
+   if (!aer_stats)
+   return;
+
+   switch (info->severity) {
+   case AER_CORRECTABLE:
+   aer_stats->dev_total_cor_errs++;
+   counter = _stats->dev_cor_errs[0];
+   max = 

Re: [PATCH v8 4/6] cpuset: Make generate_sched_domains() recognize isolated_cpus

[Patrick Bellasi]

Hi Waiman,

On 17-May 16:55, Waiman Long wrote:

[...]

> @@ -672,13 +672,14 @@ static int generate_sched_domains(cpumask_var_t 
> **domains,
>   int ndoms = 0;  /* number of sched domains in result */
>   int nslot;  /* next empty doms[] struct cpumask slot */
>   struct cgroup_subsys_state *pos_css;
> + bool root_load_balance = is_sched_load_balance(_cpuset);
>  
>   doms = NULL;
>   dattr = NULL;
>   csa = NULL;
>  
>   /* Special case for the 99% of systems with one, full, sched domain */
> - if (is_sched_load_balance(_cpuset)) {
> + if (root_load_balance && !top_cpuset.isolation_count) {

Perhaps I'm missing something but, it seems to me that, when the two
conditions above are true, then we are going to destroy and rebuild
the exact same scheduling domains.

IOW, on 99% of systems where:

   is_sched_load_balance(_cpuset)
   top_cpuset.isolation_count = 0

since boot time and forever, then every time we update a value for
cpuset.cpus we keep rebuilding the same SDs.

It's not strictly related to this patch, the same already happens in
mainline based just on the first condition, but since you are extending
that optimization, perhaps you can tell me where I'm possibly wrong or
which cases I'm not considering.

I'm interested mainly because on Android systems those conditions
are always true and we see SDs rebuilds every time we write
something in cpuset.cpus, which ultimately accounts for almost all the
6-7[ms] time required for the write to return, depending on the CPU
frequency.

Cheers Patrick

-- 
#include 

Patrick Bellasi
--
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: [RFC PATCH 0/6] net: ethernet: ti: cpsw: add MQPRIO and CBS Qdisc offload

[Grygorii Strashko]

Hi Ivan,

On 05/18/2018 04:15 PM, Ivan Khoronzhuk wrote:

This series adds MQPRIO and CBS Qdisc offload for TI cpsw driver.
It potentially can be used in audio video bridging (AVB) and time
sensitive networking (TSN).

Patchset was tested on AM572x EVM and BBB boards. Last patch from this
series adds detailed description of configuration with examples. For
consistency reasons, in role of talker and listener, tools from
patchset "TSN: Add qdisc based config interface for CBS" were used and
can be seen here: https://www.spinics.net/lists/netdev/msg460869.html

Based on net-next/master


Thanks a lot, it is great work.

In general I have no comments as of now, but I prefer to wait a bit (few 
weeks) for more comments and possible test reports.


If no comments, pls feel free to repost as final series.




Ivan Khoronzhuk (6):
   net: ethernet: ti: cpsw: use cpdma channels in backward order for txq
   net: ethernet: ti: cpdma: fit rated channels in backward order
   net: ethernet: ti: cpsw: add MQPRIO Qdisc offload
   net: ethernet: ti: cpsw: add CBS Qdisc offload
   net: ethernet: ti: cpsw: restore shaper configuration while down/up
   Documentation: networking: cpsw: add MQPRIO & CBS offload examples

  Documentation/networking/cpsw.txt   | 540 
  drivers/net/ethernet/ti/cpsw.c  | 364 +++-
  drivers/net/ethernet/ti/davinci_cpdma.c |  31 +-
  3 files changed, 913 insertions(+), 22 deletions(-)
  create mode 100644 Documentation/networking/cpsw.txt



--
regards,
-grygorii
--
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 4/5] arm64: dts: sdm845: Add serial console support

[Doug Anderson]

Rajendra,

On Tue, May 22, 2018 at 11:30 PM, Rajendra Nayak  wrote:
>
>
> On 03/30/2018 10:38 PM, Karthikeyan Ramasubramanian wrote:
>> From: Rajendra Nayak 
>>
>> Add the qup uart node and geni se instance needed to
>> support the serial console on the MTP.
>>
>> Signed-off-by: Rajendra Nayak 
>> Signed-off-by: Karthikeyan Ramasubramanian 
>> ---
>
> Andy, is it possible to pull this one in for 4.18?
> Sorry, I only realized we somehow missed this after looking at your pull 
> request.
>
> This is the only patch that prevents linux-next from booting up my sdm845 MTP
> to a minimal console shell.

It was in Andy's tree but then got dropped.  Unfortunately the clock
bindings didn't land early enough so it's a bit difficult to land any
device tree changes that use the clock bindings until the next kernel
revision...

-Doug
--
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 1/5] PCI/AER: Define and allocate aer_stats structure for AER capable devices

[Steven Rostedt]

On Wed, 23 May 2018 09:33:30 -0500
"Alex G."  wrote:

> > Well I'll agree to disagree with Linus on this one. It's ugly as fsck
> > and allows for ambiguous statements in the code.  
> 
> You misspelled "fuck".

No, Jes is Danish. That's how they spell it.

-- Steve
--
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 1/5] PCI/AER: Define and allocate aer_stats structure for AER capable devices

[Jes Sorensen]

On 05/23/2018 10:26 AM, Matthew Wilcox wrote:
> On Wed, May 23, 2018 at 10:20:10AM -0400, Jes Sorensen wrote:
>>> +++ b/drivers/pci/pcie/aer/aerdrv_stats.c
>>> @@ -0,0 +1,64 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>
>> Fix the formatting please - that gross // gibberish doesn't belong there.
> 
> Sorry, Jes.  The Chief Penguin has Spoken, and that's the preferred
> syntax:
> 
> 2. Style:
> 
>The SPDX license identifier is added in form of a comment.  The comment
>style depends on the file type::
> 
>   C source: // SPDX-License-Identifier: 
> 
> (you can dig up the discussion around this on the mailing list if you
> like.  Linus actually thinks that C++ single-line comments are one of
> the few things that language got right)

Well I'll agree to disagree with Linus on this one. It's ugly as fsck
and allows for ambiguous statements in the code.

Jes
--
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 1/5] PCI/AER: Define and allocate aer_stats structure for AER capable devices

[Alex G.]

On 05/23/2018 09:32 AM, Jes Sorensen wrote:
> On 05/23/2018 10:26 AM, Matthew Wilcox wrote:
>> On Wed, May 23, 2018 at 10:20:10AM -0400, Jes Sorensen wrote:
 +++ b/drivers/pci/pcie/aer/aerdrv_stats.c
 @@ -0,0 +1,64 @@
 +// SPDX-License-Identifier: GPL-2.0
>>>
>>> Fix the formatting please - that gross // gibberish doesn't belong there.
>>
>> Sorry, Jes.  The Chief Penguin has Spoken, and that's the preferred
>> syntax:
>>
>> 2. Style:
>>
>>The SPDX license identifier is added in form of a comment.  The comment
>>style depends on the file type::
>>
>>   C source: // SPDX-License-Identifier: 
>>
>> (you can dig up the discussion around this on the mailing list if you
>> like.  Linus actually thinks that C++ single-line comments are one of
>> the few things that language got right)
> 
> Well I'll agree to disagree with Linus on this one. It's ugly as fsck
> and allows for ambiguous statements in the code.

You misspelled "fuck".

Alex
--
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 1/5] PCI/AER: Define and allocate aer_stats structure for AER capable devices

[Jes Sorensen]

On 05/23/2018 10:26 AM, Alex G. wrote:
> On 05/23/2018 09:20 AM, Jes Sorensen wrote:
>> On 05/22/2018 06:28 PM, Rajat Jain wrote:
>>> new file mode 100644
>>> index ..b9f251992209
>>> --- /dev/null
>>> +++ b/drivers/pci/pcie/aer/aerdrv_stats.c
>>> @@ -0,0 +1,64 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>
>> Fix the formatting please - that gross // gibberish doesn't belong there.
> 
> Deep breath in. Deep breath out.
> 
> git grep SPDX
> 
> Although I don't like it, this format is already too common.

So? Just because some people did something wrong doesn't mean you should
continue to do it.

Jes
--
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 1/5] PCI/AER: Define and allocate aer_stats structure for AER capable devices

[Matthew Wilcox]

On Wed, May 23, 2018 at 10:20:10AM -0400, Jes Sorensen wrote:
> > +++ b/drivers/pci/pcie/aer/aerdrv_stats.c
> > @@ -0,0 +1,64 @@
> > +// SPDX-License-Identifier: GPL-2.0
> 
> Fix the formatting please - that gross // gibberish doesn't belong there.

Sorry, Jes.  The Chief Penguin has Spoken, and that's the preferred
syntax:

2. Style:

   The SPDX license identifier is added in form of a comment.  The comment
   style depends on the file type::

  C source: // SPDX-License-Identifier: 

(you can dig up the discussion around this on the mailing list if you
like.  Linus actually thinks that C++ single-line comments are one of
the few things that language got right)
--
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 1/5] PCI/AER: Define and allocate aer_stats structure for AER capable devices

[Alex G.]

On 05/23/2018 09:20 AM, Jes Sorensen wrote:
> On 05/22/2018 06:28 PM, Rajat Jain wrote:
>> new file mode 100644
>> index ..b9f251992209
>> --- /dev/null
>> +++ b/drivers/pci/pcie/aer/aerdrv_stats.c
>> @@ -0,0 +1,64 @@
>> +// SPDX-License-Identifier: GPL-2.0
> 
> Fix the formatting please - that gross // gibberish doesn't belong there.

Deep breath in. Deep breath out.

git grep SPDX

Although I don't like it, this format is already too common.

Cheers,
Alex
--
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 1/5] PCI/AER: Define and allocate aer_stats structure for AER capable devices

[Jes Sorensen]

On 05/22/2018 06:28 PM, Rajat Jain wrote:
> Define a structure to hold the AER statistics. There are 2 groups
> of statistics: dev_* counters that are to be collected for all AER
> capable devices and rootport_* counters that are collected for all
> (AER capable) rootports only. Allocate and free this structure when
> device is added or released (thus counters survive the lifetime of the
> device).
> 
> Add a new file aerdrv_stats.c to hold the AER stats collection logic.
> 
> Signed-off-by: Rajat Jain 
> ---
>  drivers/pci/pcie/aer/Makefile   |  2 +-
>  drivers/pci/pcie/aer/aerdrv.h   |  6 +++
>  drivers/pci/pcie/aer/aerdrv_core.c  |  9 
>  drivers/pci/pcie/aer/aerdrv_stats.c | 64 +
>  drivers/pci/probe.c |  1 +
>  include/linux/pci.h |  3 ++
>  6 files changed, 84 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/pci/pcie/aer/aerdrv_stats.c
> 
> diff --git a/drivers/pci/pcie/aer/Makefile b/drivers/pci/pcie/aer/Makefile
>  
> -aerdriver-objs := aerdrv_errprint.o aerdrv_core.o aerdrv.o
> +aerdriver-objs := aerdrv_errprint.o aerdrv_core.o aerdrv.o aerdrv_stats.o
>  aerdriver-$(CONFIG_ACPI) += aerdrv_acpi.o
>  
>  obj-$(CONFIG_PCIEAER_INJECT) += aer_inject.o
> diff --git a/drivers/pci/pcie/aer/aerdrv.h b/drivers/pci/pcie/aer/aerdrv.h
> index b4c950683cc7..d8b9fba536ed 100644
> --- a/drivers/pci/pcie/aer/aerdrv.h
> +++ b/drivers/pci/pcie/aer/aerdrv.h
> @@ -33,6 +33,10 @@
>   PCI_ERR_UNC_MALF_TLP)
>  
>  #define AER_MAX_MULTI_ERR_DEVICES5   /* Not likely to have more */
> +
> +#define AER_MAX_TYPEOF_CORRECTABLE_ERRS 16   /* as per PCI_ERR_COR_STATUS */
> +#define AER_MAX_TYPEOF_UNCORRECTABLE_ERRS 26 /* as per PCI_ERR_UNCOR_STATUS*/
> +
>  struct aer_err_info {
>   struct pci_dev *dev[AER_MAX_MULTI_ERR_DEVICES];
>   int error_dev_num;
> @@ -81,6 +85,8 @@ void aer_isr(struct work_struct *work);
>  void aer_print_error(struct pci_dev *dev, struct aer_err_info *info);
>  void aer_print_port_info(struct pci_dev *dev, struct aer_err_info *info);
>  irqreturn_t aer_irq(int irq, void *context);
> +int pci_aer_stats_init(struct pci_dev *pdev);
> +void pci_aer_stats_exit(struct pci_dev *pdev);
>  
>  #ifdef CONFIG_ACPI_APEI
>  int pcie_aer_get_firmware_first(struct pci_dev *pci_dev);
> diff --git a/drivers/pci/pcie/aer/aerdrv_core.c 
> b/drivers/pci/pcie/aer/aerdrv_core.c
> index 36e622d35c48..42a6f913069a 100644
> --- a/drivers/pci/pcie/aer/aerdrv_core.c
> +++ b/drivers/pci/pcie/aer/aerdrv_core.c
> @@ -95,9 +95,18 @@ int pci_cleanup_aer_error_status_regs(struct pci_dev *dev)
>  int pci_aer_init(struct pci_dev *dev)
>  {
>   dev->aer_cap = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ERR);
> +
> + if (!dev->aer_cap || pci_aer_stats_init(dev))
> + return -EIO;
> +
>   return pci_cleanup_aer_error_status_regs(dev);
>  }
>  
> +void pci_aer_exit(struct pci_dev *dev)
> +{
> + pci_aer_stats_exit(dev);
> +}
> +
>  /**
>   * add_error_device - list device to be handled
>   * @e_info: pointer to error info
> diff --git a/drivers/pci/pcie/aer/aerdrv_stats.c 
> b/drivers/pci/pcie/aer/aerdrv_stats.c
> new file mode 100644
> index ..b9f251992209
> --- /dev/null
> +++ b/drivers/pci/pcie/aer/aerdrv_stats.c
> @@ -0,0 +1,64 @@
> +// SPDX-License-Identifier: GPL-2.0

Fix the formatting please - that gross // gibberish doesn't belong there.

Jes
--
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/24] arm64: ilp32: add documentation on the ILP32 ABI for ARM64

[Pavel Machek]

On Wed 2018-05-16 11:18:52, Yury Norov wrote:
> Based on Andrew Pinski's patch-series.
> 
> Signed-off-by: Yury Norov 

So Andrew's signoff should be here?

> ---
>  Documentation/arm64/ilp32.txt | 45 +++
>  1 file changed, 45 insertions(+)
>  create mode 100644 Documentation/arm64/ilp32.txt
> 
> diff --git a/Documentation/arm64/ilp32.txt b/Documentation/arm64/ilp32.txt
> new file mode 100644
> index ..d0fd5109c4b2
> --- /dev/null
> +++ b/Documentation/arm64/ilp32.txt
> @@ -0,0 +1,45 @@
> +ILP32 AARCH64 SYSCALL ABI
> +=
> +
> +This document describes the ILP32 syscall ABI and where it differs
> +from the generic compat linux syscall interface.

I was hoping to learn what ILP32 is / what is it good for, but no,
this does not tell me... it would be good to do a short explanation
here, and maybe reference it from cover letter of the series...
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [RFT v2 1/4] perf cs-etm: Generate sample for missed packets

[Leo Yan]

Hi Rob,

On Wed, May 23, 2018 at 12:21:18PM +0100, Robert Walker wrote:
> Hi Leo,
> 
> On 22/05/18 10:52, Leo Yan wrote:
> >On Tue, May 22, 2018 at 04:39:20PM +0800, Leo Yan wrote:
> >
> >[...]
> >
> >Rather than the patch I posted in my previous email, I think below new
> >patch is more reasonable for me.
> >
> >In the below change, 'etmq->prev_packet' is only used to store the
> >previous CS_ETM_RANGE packet, we don't need to save CS_ETM_TRACE_ON
> >packet into 'etmq->prev_packet'.
> >
> >On the other hand, cs_etm__flush() can use 'etmq->period_instructions'
> >to indicate if need to generate instruction sample or not.  If it's
> >non-zero, then generate instruction sample and
> >'etmq->period_instructions' will be cleared; so next time if there
> >have more tracing CS_ETM_TRACE_ON packet, it can skip to generate
> >instruction sample due 'etmq->period_instructions' is zero.
> >
> >How about you think for this?
> >
> >Thanks,
> >Leo Yan
> >
> 
> I don't think this covers the cases where CS_ETM_TRACE_ON is used to
> indicate a discontinuity in the trace.  For example, there is work in
> progress to configure the ETM so that it only traces a few thousand cycles
> with a gap of many thousands of cycles between each chunk of trace - this
> can be used to sample program execution in the form of instruction events
> with branch stacks for feedback directed optimization (AutoFDO).
> 
> In this case, the raw trace is something like:
> 
> ...
> I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0x007E7B886908;
> I_ATOM_F3 : Atom format 3.; EEN
> I_ATOM_F1 : Atom format 1.; E
> # Trace stops here
> 
> # Some time passes, and then trace is turned on again
> I_TRACE_ON : Trace On.
> I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit, IS0.;
> Addr=0x0057224322F4; Ctxt: AArch64,EL0, NS;
> I_ATOM_F3 : Atom format 3.; ENN
> I_ATOM_F5 : Atom format 5.; ENENE
> ...
> 
> This results in the following packets from the decoder:
> 
> CS_ETM_RANGE: [0x7e7b886908-0x7e7b886930] br
> CS_ETM_RANGE: [0x7e7b88699c-0x7e7b8869a4] br
> CS_ETM_RANGE: [0x7e7b8869d8-0x7e7b8869f0]
> CS_ETM_RANGE: [0x7e7b8869f0-0x7e7b8869fc] br
> CS_ETM_TRACE_ON
> CS_ETM_RANGE: [0x57224322f4-0x5722432304] br
> CS_ETM_RANGE: [0x57224320e8-0x57224320ec]
> CS_ETM_RANGE: [0x57224320ec-0x57224320f8]
> CS_ETM_RANGE: [0x57224320f8-0x572243212c] br
> CS_ETM_RANGE: [0x5722439b80-0x5722439bec]
> CS_ETM_RANGE: [0x5722439bec-0x5722439c14] br
> CS_ETM_RANGE: [0x5722437c30-0x5722437c6c]
> CS_ETM_RANGE: [0x5722437c6c-0x5722437c7c] br
> 
> Without handling the CS_ETM_TRACE_ON, this would be interpreted as a branch
> from 0x7e7b8869f8 to 0x57224322f4, when there is actually a gap of many
> thousand instructions between these.
> 
> I think this patch will break the branch stacks - by removing the
> prev_packet swap from cs_etm__flush(), the next time a CS_ETM_RANGE packet
> is handled, cs_etm__sample() will see prev_packet contains the last
> CS_ETM_RANGE from the previous block of trace, causing an erroneous call to
> cs_etm__update_last_branch_rb().  In the example above, the branch stack
> will contain an erroneous branch from 0x7e7b8869f8 to 0x57224322f4.
> 
> I think what you need to do is add a check for the previous packet being a
> CS_ETM_TRACE_ON when determining the generate_sample value.

I still can see there have hole for packets handling with your
suggestion, let's focus on below three packets:

CS_ETM_RANGE:[0x7e7b8869f0-0x7e7b8869fc] br
CS_ETM_TRACE_ON: [0xdeadbeefdeadbeef-0xdeadbeefdeadbeef]
CS_ETM_RANGE:[0x57224322f4-0x5722432304] br

When the CS_ETM_TRACE_ON packet is coming, cs_etm__flush() doesn't
handle for 'etmq->prev_packet' to generate branch sample, this results
in we miss the info for 0x7e7b8869fc, and with packet swapping
'etmq->prev_packet' is assigned to CS_ETM_TRACE_ON packet.

When the last CS_ETM_RANGE packet is coming, cs_etm__sample() will
combine the values from CS_ETM_TRACE_ON packet and the last
CS_ETM_RANGE packet to generate branch sample packet; at the end
we get below sample packets:

  packet(n):   sample::addr=0x7e7b8869f0
  packet(n+1): sample::ip=0xdeadbeefdeadbeeb sample::addr=0x57224322f4

So I think we also need to generate branch sample, and we can get
below results:

  packet(n):   sample::addr=0x7e7b8869f0
  packet(n+1): sample::ip=0x7e7b8869f8 sample::addr=0xdeadbeefdeadbeef
  packet(n+2): sample::ip=0xdeadbeefdeadbeeb sample::addr=0x57224322f4

So we also can rely on this to get to know there have one address
range is [0xdeadbeefdeadbeef..0xdeadbeefdeadbeeb] to indicate there
have a discontinuity in the trace.

> Regards
> 
> Rob
> 
> >
> >diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> >index 822ba91..dd354ad 100644
> >--- a/tools/perf/util/cs-etm.c
> >+++ b/tools/perf/util/cs-etm.c
> >@@ -495,6 +495,13 @@ static inline void cs_etm__reset_last_branch_rb(struct 
> >cs_etm_queue *etmq)
> >  static inline u64 cs_etm__last_executed_instr(struct 

[PATCH bpf-next v2 1/3] bpf: add ability to configure unprivileged BPF via boot-time parameter

[Eugene Syromiatnikov]

This patch introduces two configuration options,
UNPRIVILEGED_BPF_BOOTPARAM and UNPRIVILEGED_BPF_BOOTPARAM_VALUE, that
allow configuring the initial value of kernel.unprivileged_bpf_disabled
sysctl knob, which is useful for the cases when disabling unprivileged
bpf() access during the early boot is desirable.

Signed-off-by: Eugene Syromiatnikov 
---
 Documentation/admin-guide/kernel-parameters.txt |  8 +++
 init/Kconfig| 31 +
 kernel/bpf/syscall.c| 16 +
 3 files changed, 55 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 11fc28e..aa8e831 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4355,6 +4355,14 @@
unknown_nmi_panic
[X86] Cause panic on unknown NMI.
 
+   unprivileged_bpf_disabled=
+   Format: { "0" | "1" }
+   Sets initial value of kernel.unprivileged_bpf_disabled
+   sysctl knob.
+   0 - unprivileged bpf() syscall access enabled.
+   1 - unprivileged bpf() syscall access disabled.
+   Default value is set via kernel config option.
+
usbcore.authorized_default=
[USB] Default USB device authorization:
(default -1 = authorized except for wireless USB,
diff --git a/init/Kconfig b/init/Kconfig
index 480a4f2..1403a3e 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1404,6 +1404,37 @@ config BPF_JIT_ALWAYS_ON
  Enables BPF JIT and removes BPF interpreter to avoid
  speculative execution of BPF instructions by the interpreter
 
+config UNPRIVILEGED_BPF_BOOTPARAM
+   bool "Unprivileged bpf() boot parameter"
+   depends on BPF_SYSCALL
+   default n
+   help
+ This option adds a kernel parameter 'unprivileged_bpf_disabled'
+ that allows configuring default state of the
+ kernel.unprivileged_bpf_disabled sysctl knob.
+ If this option is selected, unprivileged access to the bpf() syscall
+ can be disabled with unprivileged_bpf_disabled=1 on the kernel command
+ line.  The purpose of this option is to allow disabling unprivileged
+ bpf() syscall access during the early boot.
+
+ If you are unsure how to answer this question, answer N.
+
+config UNPRIVILEGED_BPF_BOOTPARAM_VALUE
+   int "Unprivileged bpf() boot parameter default value"
+   depends on UNPRIVILEGED_BPF_BOOTPARAM
+   range 0 1
+   default 0
+   help
+ This option sets the default value for the kernel parameter
+ 'unprivileged_bpf_disabled', which allows disabling unprivileged bpf()
+ syscall access at boot.  If this option is set to 0 (zero), the
+ unprivileged bpf() boot kernel parameter will default to 0, allowing
+ unprivileged bpf() syscall access at bootup.  If this option is
+ set to 1 (one), the unprivileged bpf() kernel parameter will default
+ to 1, disabling unprivileged bpf() syscall access at bootup.
+
+ If you are unsure how to answer this question, answer 0.
+
 config USERFAULTFD
bool "Enable userfaultfd() system call"
select ANON_INODES
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index bfcde94..fdc5fd9 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define IS_FD_ARRAY(map) ((map)->map_type == BPF_MAP_TYPE_PROG_ARRAY || \
   (map)->map_type == BPF_MAP_TYPE_PERF_EVENT_ARRAY || \
@@ -45,7 +46,22 @@ static DEFINE_SPINLOCK(prog_idr_lock);
 static DEFINE_IDR(map_idr);
 static DEFINE_SPINLOCK(map_idr_lock);
 
+#ifdef CONFIG_UNPRIVILEGED_BPF_BOOTPARAM
+int sysctl_unprivileged_bpf_disabled __read_mostly =
+   CONFIG_UNPRIVILEGED_BPF_BOOTPARAM_VALUE;
+
+static int __init unprivileged_bpf_setup(char *str)
+{
+   unsigned long disabled;
+
+   if (!kstrtoul(str, 0, ))
+   sysctl_unprivileged_bpf_disabled = !!disabled;
+   return 1;
+}
+__setup("unprivileged_bpf_disabled=", unprivileged_bpf_setup);
+#else /* !CONFIG_UNPRIVILEGED_BPF_BOOTPARAM */
 int sysctl_unprivileged_bpf_disabled __read_mostly;
+#endif /* CONFIG_UNPRIVILEGED_BPF_BOOTPARAM */
 
 static const struct bpf_map_ops * const bpf_map_types[] = {
 #define BPF_PROG_TYPE(_id, _ops)
-- 
2.1.4

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

[PATCH bpf-next v2 3/3] bpf: add ability to configure BPF JIT kallsyms export at the boot time

[Eugene Syromiatnikov]

This patch introduces two configuration options,
BPF_JIT_KALLSYMS_BOOTPARAM and BPF_JIT_KALLSYMS_BOOTPARAM_VALUE, that
allow configuring the initial value of net.core.bpf_jit_kallsyms sysctl
knob. This enables export of addresses of JIT'ed BPF programs that
created during the early boot.

Signed-off-by: Eugene Syromiatnikov 
---
 Documentation/admin-guide/kernel-parameters.txt | 10 +
 init/Kconfig| 30 +
 kernel/bpf/core.c   | 14 
 3 files changed, 54 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 5adc6d0..10e7502 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -452,6 +452,16 @@
2 - JIT hardening is enabled for all users.
Default value is set via kernel config option.
 
+   bpf_jit_kallsyms=
+   Format: { "0" | "1" }
+   Sets initial value of net.core.bpf_jit_kallsyms
+   sysctl knob.
+   0 - Addresses of JIT'ed BPF programs are not exported
+   to kallsyms.
+   1 - Export of addresses of JIT'ed BPF programs is
+   enabled for privileged users.
+   Default value is set via kernel config option.
+
bttv.card=  [HW,V4L] bttv (bt848 + bt878 based grabber cards)
bttv.radio= Most important insmod options are available as
kernel args too.
diff --git a/init/Kconfig b/init/Kconfig
index b661497..b5405ca 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1464,6 +1464,36 @@ config BPF_JIT_HARDEN_BOOTPARAM_VALUE
 
  If you are unsure how to answer this question, answer 0.
 
+config BPF_JIT_KALLSYMS_BOOTPARAM
+   bool "BPF JIT kallsyms export boot parameter"
+   default n
+   help
+ This option adds a kernel parameter 'bpf_jit_kallsyms' that allows
+ configuring default state of the net.core.bpf_jit_kallsyms sysctl
+ knob.  If this option is selected, the default value of the
+ net.core.bpf_jit_kallsyms sysctl knob can be set on the kernel command
+ line.  The purpose of this option is to allow enabling BPF JIT
+ kallsyms export for the BPF programs created during the early boot,
+ so they can be traced later.
+
+ If you are unsure how to answer this question, answer N.
+
+config BPF_JIT_KALLSYMS_BOOTPARAM_VALUE
+   int "BPF JIT kallsyms export boot parameter default value"
+   depends on BPF_JIT_HARDEN_BOOTPARAM
+   range 0 1
+   default 0
+   help
+ This option sets the default value for the kernel parameter
+ 'bpf_jit_kallsyms' that configures default value of the
+ net.core.bpf_jit_kallsyms sysctl knob at boot.  If this option is set
+ to 0 (zero), the net.core.bpf_jit_kallsyms will default to 0, which
+ will lead to disabling of exporting of addresses of JIT'ed BPF
+ programs.  If this option is set to 1 (one), addresses of privileged
+ BPF programs are exported to kallsyms.
+
+ If you are unsure how to answer this question, answer 0.
+
 config USERFAULTFD
bool "Enable userfaultfd() system call"
select ANON_INODES
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 9edb7a8..003d708 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -321,7 +321,21 @@ __setup("bpf_jit_harden=", bpf_jit_harden_setup);
 int bpf_jit_harden   __read_mostly;
 #endif /* CONFIG_BPF_JIT_HARDEN_BOOTPARAM */
 
+#ifdef CONFIG_BPF_JIT_KALLSYMS_BOOTPARAM
+int bpf_jit_kallsyms __read_mostly = CONFIG_BPF_JIT_KALLSYMS_BOOTPARAM_VALUE;
+
+static int __init bpf_jit_kallsyms_setup(char *str)
+{
+   unsigned long enabled;
+
+   if (!kstrtoul(str, 0, ))
+   bpf_jit_kallsyms = !!enabled;
+   return 1;
+}
+__setup("bpf_jit_kallsyms=", bpf_jit_kallsyms_setup);
+#else /* !CONFIG_BPF_JIT_KALLSYMS_BOOTPARAM */
 int bpf_jit_kallsyms __read_mostly;
+#endif /* CONFIG_BPF_JIT_KALLSYMS_BOOTPARAM */
 
 static __always_inline void
 bpf_get_prog_addr_region(const struct bpf_prog *prog,
-- 
2.1.4

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

[PATCH bpf-next v2 2/3] bpf: add ability to configure BPF JIT hardening via boot-time parameter

[Eugene Syromiatnikov]

This patch introduces two configuration options,
BPF_JIT_HARDEN_BOOTPARAM and BPF_JIT_HARDEN_BOOTPARAM_VALUE, that allow
configuring the initial value of net.core.bpf_jit_harden sysctl knob,
which is useful for enforcing JIT hardening during the early boot.

Signed-off-by: Eugene Syromiatnikov 
---
 Documentation/admin-guide/kernel-parameters.txt | 10 +
 init/Kconfig| 29 +
 kernel/bpf/core.c   | 17 +++
 3 files changed, 56 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index aa8e831..5adc6d0 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -442,6 +442,16 @@
bert_disable[ACPI]
Disable BERT OS support on buggy BIOSes.
 
+   bpf_jit_harden=
+   Format: { "0" | "1" | "2" }
+   Sets initial value of net.core.bpf_jit_harden
+   sysctl knob.
+   0 - JIT hardening is disabled.
+   1 - JIT hardening is enabled for unprivileged users
+   only.
+   2 - JIT hardening is enabled for all users.
+   Default value is set via kernel config option.
+
bttv.card=  [HW,V4L] bttv (bt848 + bt878 based grabber cards)
bttv.radio= Most important insmod options are available as
kernel args too.
diff --git a/init/Kconfig b/init/Kconfig
index 1403a3e..b661497 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1435,6 +1435,35 @@ config UNPRIVILEGED_BPF_BOOTPARAM_VALUE
 
  If you are unsure how to answer this question, answer 0.
 
+config BPF_JIT_HARDEN_BOOTPARAM
+   bool "BPF JIT harden boot parameter"
+   default n
+   help
+ This option adds a kernel parameter 'bpf_jit_harden' that allows
+ configuring default state of the net.core.bpf_jit_harden sysctl knob.
+ If this option is selected, the default value of the
+ net.core.bpf_jit_harden sysctl knob can be set on the kernel command
+ line.  The purpose of this option is to allow enabling BPF JIT
+ hardening for the BPF programs created during the early boot.
+
+ If you are unsure how to answer this question, answer N.
+
+config BPF_JIT_HARDEN_BOOTPARAM_VALUE
+   int "BPF JIT harden boot parameter default value"
+   depends on BPF_JIT_HARDEN_BOOTPARAM
+   range 0 2
+   default 0
+   help
+ This option sets the default value for the kernel parameter
+ 'bpf_jit_enabled' that configures default value of the
+ net.core.bpf_jit_harden sysctl knob at boot.  If this option is set to
+ 0 (zero), the net.core.bpf_jit_harden will default to 0, which will
+ lead to no hardening at bootup.  If this option is set to 1 (one),
+ hardening will be applied only to unprivileged users only.  If this
+ option is set to 2 (two), JIT hardening will be enabled for all users.
+
+ If you are unsure how to answer this question, answer 0.
+
 config USERFAULTFD
bool "Enable userfaultfd() system call"
select ANON_INODES
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 2194c6a..9edb7a8 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -303,7 +304,23 @@ struct bpf_prog *bpf_patch_insn_single(struct bpf_prog 
*prog, u32 off,
 #ifdef CONFIG_BPF_JIT
 /* All BPF JIT sysctl knobs here. */
 int bpf_jit_enable   __read_mostly = IS_BUILTIN(CONFIG_BPF_JIT_ALWAYS_ON);
+
+#ifdef CONFIG_BPF_JIT_HARDEN_BOOTPARAM
+int bpf_jit_harden   __read_mostly = CONFIG_BPF_JIT_HARDEN_BOOTPARAM_VALUE;
+
+static int __init bpf_jit_harden_setup(char *str)
+{
+   unsigned long value;
+
+   if (!kstrtoul(str, 0, ))
+   bpf_jit_harden = min(value, 2UL);
+   return 1;
+}
+__setup("bpf_jit_harden=", bpf_jit_harden_setup);
+#else /* !CONFIG_BPF_JIT_HARDEN_BOOTPARAM */
 int bpf_jit_harden   __read_mostly;
+#endif /* CONFIG_BPF_JIT_HARDEN_BOOTPARAM */
+
 int bpf_jit_kallsyms __read_mostly;
 
 static __always_inline void
-- 
2.1.4

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

[PATCH bpf-next v2 0/3] bpf: add boot parameters for sysctl knobs

[Eugene Syromiatnikov]

Some BPF sysctl knobs affect the loading of BPF programs, and during
system boot/init stages these sysctls are not yet configured.
A concrete example is systemd, that has implemented loading of BPF
programs.

Thus, to allow controlling these setting at early boot, this patch set
adds the ability to change the default setting of these sysctl knobs
as well as option to override them via a boot-time kernel parameter
(in order to avoid rebuilding kernel each time a need of changing these
defaults arises).

The sysctl knobs in question are kernel.unprivileged_bpf_disable,
net.core.bpf_jit_harden, and net.core.bpf_jit_kallsyms.

Eugene Syromiatnikov (3):
  bpf: add ability to configure unprivileged BPF via boot-time parameter
  bpf: add ability to configure BPF JIT hardening via boot-time
parameter
  bpf: add ability to configure BPF JIT kallsyms export at the boot time

 Documentation/admin-guide/kernel-parameters.txt | 28 
 init/Kconfig| 90 +
 kernel/bpf/core.c   | 31 +
 kernel/bpf/syscall.c| 16 +
 4 files changed, 165 insertions(+)

-- 
2.1.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 RFC V2 2/6] hwmon: Add support for RPi voltage sensor

[Robin Murphy]

On 22/05/18 20:31, Stefan Wahren wrote:
[...]

+static int rpi_hwmon_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct rpi_hwmon_data *data;
+   int ret;
+
+   data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+   if (!data)
+   return -ENOMEM;
+
+   data->fw = platform_get_drvdata(to_platform_device(dev->parent));
+   if (!data->fw)
+   return -EPROBE_DEFER;
+


I am a bit at loss here (and sorry I didn't bring this up before).
How would this ever be possible, given that the driver is registered
from the firmware driver ?


Do you refer to the (wrong) return code, the assumption that the parent must be 
a platform driver or a possible race?



The return code is one thing. My question was how the driver would ever be 
instantiated
with platform_get_drvdata(to_platform_device(dev->parent)) == NULL (but 
dev->parent != NULL),
so I referred to the race. But, sure, a second question would be how that would 
indicate
that the parent is not instantiated yet (which by itself seems like an odd 
question).


This shouldn't happen and worth a log error. In patch #3 the registration is 
called after the complete private data of the firmware driver is initialized. 
Did i missed something?

But i must confess that i didn't test all builtin/module combinations.


The point is that, by construction, a "raspberrypi-hwmon" device will 
only ever be created for this driver to bind to if the firmware device 
is both fully initialised and known to support the GET_THROTTLED call 
already. Thus trying to check those again from the hwmon driver is at 
best pointless, and at worst misleading. If somebody *does* manage to 
bind this driver to some random inappropriate device, you've still got 
no guarantee that dev->parent is valid or that 
dev_get_drvdata(dev->parent)) won't return something non-NULL that isn't 
a struct rpi_firmware pointer, at which point you're liable to pass the 
paranoid check yet still crash anyway.


IOW, you can't reasonably defend against incorrect operation, and under 
correct operation there's nothing to defend against, so either way it's 
pretty futile to waste effort trying.


Robin.
--
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 0/3] bpf: add boot parameters for sysctl knobs

[Jesper Dangaard Brouer]

On Wed, 23 May 2018 13:35:47 +0200
Eugene Syromiatnikov  wrote:

> On Mon, May 21, 2018 at 11:58:13AM -0700, Alexei Starovoitov wrote:
> > On Mon, May 21, 2018 at 02:29:30PM +0200, Eugene Syromiatnikov wrote:  
> > > Hello.
> > > 
> > > This patch set adds ability to set default values for
> > > kernel.unprivileged_bpf_disable, net.core.bpf_jit_harden,
> > > net.core.bpf_jit_kallsyms sysctl knobs as well as option to override
> > > them via a boot-time kernel parameter.  
> > 
> > Commits log not only should explain 'what' is being done by the patch,
> > but 'why' as well.  
> 
> Some BPF sysctl knobs affect the loading of BPF programs, and during
> system boot/init stages these sysctls are not yet configured. A
> concrete example is systemd, that has implemented loading of BPF
> programs.
> 
> Thus, to allow controlling these setting at early boot, this patch set
> adds the ability to change the default setting of these sysctl knobs
> as well as option to override them via a boot-time kernel parameter
> (in order to avoid rebuilding kernel each time a need of changing these
> defaults arises).
> 
> The sysctl knobs in question are kernel.unprivileged_bpf_disable,
> net.core.bpf_jit_harden, and net.core.bpf_jit_kallsyms.

Hi Eugene,

You have to resend the entire patchset with this explanation in the
cover-letter.  Your old patchset have been dropped from patchwork[1]
due to being marked with "Changes Requested".

Please remember to give it a "V2" tag and also specify which git tree
you are targeting[2], like [PATCH bpf-next V2].


[1] http://patchwork.ozlabs.org/project/netdev/list/?series=45617=%2a

[2] 
https://github.com/netoptimizer/linux/blob/bpf_doc10/Documentation/bpf/bpf_devel_QA.rst#q-how-do-i-indicate-which-tree-bpf-vs-bpf-next-my-patch-should-be-applied-to
-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer
--
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 0/3] bpf: add boot parameters for sysctl knobs

[Eugene Syromiatnikov]

On Mon, May 21, 2018 at 11:58:13AM -0700, Alexei Starovoitov wrote:
> On Mon, May 21, 2018 at 02:29:30PM +0200, Eugene Syromiatnikov wrote:
> > Hello.
> > 
> > This patch set adds ability to set default values for
> > kernel.unprivileged_bpf_disable, net.core.bpf_jit_harden,
> > net.core.bpf_jit_kallsyms sysctl knobs as well as option to override
> > them via a boot-time kernel parameter.
> 
> Commits log not only should explain 'what' is being done by the patch,
> but 'why' as well.

Some BPF sysctl knobs affect the loading of BPF programs, and during
system boot/init stages these sysctls are not yet configured. A
concrete example is systemd, that has implemented loading of BPF
programs.

Thus, to allow controlling these setting at early boot, this patch set
adds the ability to change the default setting of these sysctl knobs
as well as option to override them via a boot-time kernel parameter
(in order to avoid rebuilding kernel each time a need of changing these
defaults arises).

The sysctl knobs in question are kernel.unprivileged_bpf_disable,
net.core.bpf_jit_harden, and net.core.bpf_jit_kallsyms.
--
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: [RFT v2 1/4] perf cs-etm: Generate sample for missed packets

[Robert Walker]

Hi Leo,

On 22/05/18 10:52, Leo Yan wrote:

On Tue, May 22, 2018 at 04:39:20PM +0800, Leo Yan wrote:

[...]

Rather than the patch I posted in my previous email, I think below new
patch is more reasonable for me.

In the below change, 'etmq->prev_packet' is only used to store the
previous CS_ETM_RANGE packet, we don't need to save CS_ETM_TRACE_ON
packet into 'etmq->prev_packet'.

On the other hand, cs_etm__flush() can use 'etmq->period_instructions'
to indicate if need to generate instruction sample or not.  If it's
non-zero, then generate instruction sample and
'etmq->period_instructions' will be cleared; so next time if there
have more tracing CS_ETM_TRACE_ON packet, it can skip to generate
instruction sample due 'etmq->period_instructions' is zero.

How about you think for this?

Thanks,
Leo Yan



I don't think this covers the cases where CS_ETM_TRACE_ON is used to 
indicate a discontinuity in the trace.  For example, there is work in 
progress to configure the ETM so that it only traces a few thousand 
cycles with a gap of many thousands of cycles between each chunk of 
trace - this can be used to sample program execution in the form of 
instruction events with branch stacks for feedback directed optimization 
(AutoFDO).


In this case, the raw trace is something like:

...
I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0x007E7B886908;
I_ATOM_F3 : Atom format 3.; EEN
I_ATOM_F1 : Atom format 1.; E
# Trace stops here

# Some time passes, and then trace is turned on again
I_TRACE_ON : Trace On.
I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit, IS0.; 
Addr=0x0057224322F4; Ctxt: AArch64,EL0, NS;

I_ATOM_F3 : Atom format 3.; ENN
I_ATOM_F5 : Atom format 5.; ENENE
...

This results in the following packets from the decoder:

CS_ETM_RANGE: [0x7e7b886908-0x7e7b886930] br
CS_ETM_RANGE: [0x7e7b88699c-0x7e7b8869a4] br
CS_ETM_RANGE: [0x7e7b8869d8-0x7e7b8869f0]
CS_ETM_RANGE: [0x7e7b8869f0-0x7e7b8869fc] br
CS_ETM_TRACE_ON
CS_ETM_RANGE: [0x57224322f4-0x5722432304] br
CS_ETM_RANGE: [0x57224320e8-0x57224320ec]
CS_ETM_RANGE: [0x57224320ec-0x57224320f8]
CS_ETM_RANGE: [0x57224320f8-0x572243212c] br
CS_ETM_RANGE: [0x5722439b80-0x5722439bec]
CS_ETM_RANGE: [0x5722439bec-0x5722439c14] br
CS_ETM_RANGE: [0x5722437c30-0x5722437c6c]
CS_ETM_RANGE: [0x5722437c6c-0x5722437c7c] br

Without handling the CS_ETM_TRACE_ON, this would be interpreted as a 
branch from 0x7e7b8869f8 to 0x57224322f4, when there is actually a gap 
of many thousand instructions between these.


I think this patch will break the branch stacks - by removing the 
prev_packet swap from cs_etm__flush(), the next time a CS_ETM_RANGE 
packet is handled, cs_etm__sample() will see prev_packet contains the 
last CS_ETM_RANGE from the previous block of trace, causing an erroneous 
call to cs_etm__update_last_branch_rb().  In the example above, the 
branch stack will contain an erroneous branch from 0x7e7b8869f8 to 
0x57224322f4.


I think what you need to do is add a check for the previous packet being 
a CS_ETM_TRACE_ON when determining the generate_sample value.


Regards

Rob



diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 822ba91..dd354ad 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -495,6 +495,13 @@ static inline void cs_etm__reset_last_branch_rb(struct 
cs_etm_queue *etmq)
  static inline u64 cs_etm__last_executed_instr(struct cs_etm_packet *packet)
  {
/*
+* The packet is the start tracing packet if the end_addr is zero,
+* returns 0 for this case.
+*/
+   if (!packet->end_addr)
+   return 0;
+
+   /*
 * The packet records the execution range with an exclusive end address
 *
 * A64 instructions are constant size, so the last executed
@@ -897,13 +904,27 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
etmq->period_instructions = instrs_over;
}
  
-	if (etm->sample_branches &&

-   etmq->prev_packet &&
-   etmq->prev_packet->sample_type == CS_ETM_RANGE &&
-   etmq->prev_packet->last_instr_taken_branch) {
-   ret = cs_etm__synth_branch_sample(etmq);
-   if (ret)
-   return ret;
+   if (etm->sample_branches && etmq->prev_packet) {
+   bool generate_sample = false;
+
+   /* Generate sample for start tracing packet */
+   if (etmq->prev_packet->sample_type == 0)
+   generate_sample = true;


Also check for etmq->prev_packet->sample_type == CS_ETM_TRACE_ON here 
and set generate_sample = true.



+
+   /* Generate sample for exception packet */
+   if (etmq->prev_packet->exc == true)
+   generate_sample = true;
+
+   /* Generate sample for normal branch packet */
+   if (etmq->prev_packet->sample_type == CS_ETM_RANGE &&
+   

Re: [PATCH 1/5] PCI/AER: Define and allocate aer_stats structure for AER capable devices

[Greg Kroah-Hartman]

On Tue, May 22, 2018 at 03:28:01PM -0700, Rajat Jain wrote:
> --- /dev/null
> +++ b/drivers/pci/pcie/aer/aerdrv_stats.c
> @@ -0,0 +1,64 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + *  Copyright (C) 2018 Google Inc, All Rights Reserved.
> + *  Rajat Jain (raja...@google.com)

Google has the copyright, not you, right?  You might want to make that a
bit more explicit by putting a blank line somewhere here...

> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.

If you have a SPDX line, you do not need this paragraph.  Please drop it
so we don't have to delete it later on.

thanks,

greg k-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 3/5] PCP/AER: Add sysfs attributes to provide breakdown of AERs

[Greg Kroah-Hartman]

On Tue, May 22, 2018 at 03:28:03PM -0700, Rajat Jain wrote:
> Add sysfs attributes to provide breakdown of the AERs seen,
> into different type of correctable or uncorrectable errors:
> 
> dev_breakdown_correctable
> dev_breakdown_uncorrectable
> 
> Signed-off-by: Rajat Jain 
> ---
>  drivers/pci/pcie/aer/aerdrv.h  |  6 ++
>  drivers/pci/pcie/aer/aerdrv_errprint.c |  6 --
>  drivers/pci/pcie/aer/aerdrv_stats.c| 25 +
>  3 files changed, 35 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/pcie/aer/aerdrv.h b/drivers/pci/pcie/aer/aerdrv.h
> index b5d5ad6f2c03..048fbd7c9633 100644
> --- a/drivers/pci/pcie/aer/aerdrv.h
> +++ b/drivers/pci/pcie/aer/aerdrv.h
> @@ -89,6 +89,12 @@ int pci_aer_stats_init(struct pci_dev *pdev);
>  void pci_aer_stats_exit(struct pci_dev *pdev);
>  void pci_dev_aer_stats_incr(struct pci_dev *pdev, struct aer_err_info *info);
>  
> +extern const char
> +*aer_correctable_error_string[AER_MAX_TYPEOF_CORRECTABLE_ERRS];
> +
> +extern const char
> +*aer_uncorrectable_error_string[AER_MAX_TYPEOF_UNCORRECTABLE_ERRS];
> +
>  #ifdef CONFIG_ACPI_APEI
>  int pcie_aer_get_firmware_first(struct pci_dev *pci_dev);
>  #else
> diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c 
> b/drivers/pci/pcie/aer/aerdrv_errprint.c
> index 5e8b98deda08..5585f309f1a8 100644
> --- a/drivers/pci/pcie/aer/aerdrv_errprint.c
> +++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
> @@ -68,7 +68,8 @@ static const char *aer_error_layer[] = {
>   "Transaction Layer"
>  };
>  
> -static const char *aer_correctable_error_string[] = {
> +const char
> +*aer_correctable_error_string[AER_MAX_TYPEOF_CORRECTABLE_ERRS] = {
>   "Receiver Error",   /* Bit Position 0   */
>   NULL,
>   NULL,
> @@ -87,7 +88,8 @@ static const char *aer_correctable_error_string[] = {
>   "Header Log Overflow",  /* Bit Position 15  */
>  };
>  
> -static const char *aer_uncorrectable_error_string[] = {
> +const char
> +*aer_uncorrectable_error_string[AER_MAX_TYPEOF_UNCORRECTABLE_ERRS] = {
>   "Undefined",/* Bit Position 0   */
>   NULL,
>   NULL,
> diff --git a/drivers/pci/pcie/aer/aerdrv_stats.c 
> b/drivers/pci/pcie/aer/aerdrv_stats.c
> index 87b7119d0a86..5f0a6e144f56 100644
> --- a/drivers/pci/pcie/aer/aerdrv_stats.c
> +++ b/drivers/pci/pcie/aer/aerdrv_stats.c
> @@ -61,10 +61,35 @@ aer_stats_aggregate_attr(dev_total_cor_errs);
>  aer_stats_aggregate_attr(dev_total_fatal_errs);
>  aer_stats_aggregate_attr(dev_total_nonfatal_errs);
>  
> +#define aer_stats_breakdown_attr(field, stats_array, strings_array)  
>   \
> + static ssize_t \
> + field##_show(struct device *dev, struct device_attribute *attr,\
> +  char *buf)\
> +{
>   \
> + unsigned int i;\
> + char *str = buf;   \
> + struct pci_dev *pdev = to_pci_dev(dev);\
> + u64 *stats = pdev->aer_stats->stats_array; \
> + for (i = 0; i < ARRAY_SIZE(strings_array); i++) {  \
> + if (strings_array[i])  \
> + str += sprintf(str, "%s = 0x%llx\n",   \
> +strings_array[i], stats[i]);\
> + }  \
> + return str-buf;\
> +}
>   \

Again with the tabs instead of spaces please.

thanks,

greg k-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 2/5] PCI/AER: Add sysfs stats for AER capable devices

[Greg Kroah-Hartman]

On Tue, May 22, 2018 at 03:28:02PM -0700, Rajat Jain wrote:
> +#define aer_stats_aggregate_attr(field)  
>   \
> + static ssize_t \
> + field##_show(struct device *dev, struct device_attribute *attr,\
> +  char *buf)\
> +{
>   \
> + struct pci_dev *pdev = to_pci_dev(dev);\
> + return sprintf(buf, "0x%llx\n", pdev->aer_stats->field);   \
> +}
>   \

Use tabs at the end please, otherwise your trailing \ look horrid.

> +static DEVICE_ATTR_RO(field)
> +
> +aer_stats_aggregate_attr(dev_total_cor_errs);
> +aer_stats_aggregate_attr(dev_total_fatal_errs);
> +aer_stats_aggregate_attr(dev_total_nonfatal_errs);
> +
> +static struct attribute *aer_stats_attrs[] __ro_after_init = {
> + _attr_dev_total_cor_errs.attr,
> + _attr_dev_total_fatal_errs.attr,
> + _attr_dev_total_nonfatal_errs.attr,
> + NULL
> +};
> +
> +static umode_t aer_stats_attrs_are_visible(struct kobject *kobj,
> +struct attribute *a, int n)
> +{
> + struct device *dev = kobj_to_dev(kobj);
> + struct pci_dev *pdev = to_pci_dev(dev);
> +
> + if (!pdev->aer_stats)
> + return 0;
> +
> + return a->mode;
> +}
> +
> +const struct attribute_group aer_stats_attr_group = {
> + .name  = "aer_stats",
> + .attrs  = aer_stats_attrs,
> + .is_visible = aer_stats_attrs_are_visible,
> +};
> +
> +void pci_dev_aer_stats_incr(struct pci_dev *pdev, struct aer_err_info *info)
> +{
> + int status, i, max = -1;
> + u64 *counter = NULL;
> + struct aer_stats *aer_stats = pdev->aer_stats;
> +
> + if (unlikely(!aer_stats))
> + return;

Can you measure the speed difference with and without that unlikely()
macro?  If not, please don't use it.  Hint, the cpu and compiler are
always always better at this than we are...

thanks,

greg k-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 5/5] Documentation/PCI: Add details of PCI AER statistics

[Greg Kroah-Hartman]

On Tue, May 22, 2018 at 03:28:05PM -0700, Rajat Jain wrote:
> Add the PCI AER statistics details to
> Documentation/PCI/pcieaer-howto.txt
> 
> Signed-off-by: Rajat Jain 
> ---
>  Documentation/PCI/pcieaer-howto.txt | 35 +
>  1 file changed, 35 insertions(+)
> 
> diff --git a/Documentation/PCI/pcieaer-howto.txt 
> b/Documentation/PCI/pcieaer-howto.txt
> index acd06bb8..86ee9f9ff5e1 100644
> --- a/Documentation/PCI/pcieaer-howto.txt
> +++ b/Documentation/PCI/pcieaer-howto.txt
> @@ -73,6 +73,41 @@ In the example, 'Requester ID' means the ID of the device 
> who sends
>  the error message to root port. Pls. refer to pci express specs for
>  other fields.
>  
> +2.4 AER statistics
> +
> +When AER messages are captured, the statistics are exposed via the following
> +sysfs attributes under the "aer_stats" folder for the device:
> +
> +2.4.1 Device sysfs Attributes
> +
> +These attributes show up under all the devices that are AER capable. These
> +indicate the errors "as seen by the device". Note that this may mean that if
> +an end point is causing problems, the AER counters may increment at its link
> +partner (e.g. root port) because the errors will be "seen" by the link 
> partner
> +and not the the problematic end point itself (which may report all counters
> +as 0 as it never saw any problems).
> +
> + * dev_total_cor_errs: number of correctable errors seen by the device.
> + * dev_total_fatal_errs: number of fatal uncorrectable errors seen by the 
> device.
> + * dev_total_nonfatal_errs: number of nonfatal uncorr errors seen by the 
> device.
> + * dev_breakdown_correctable: Provides a breakdown of different type of
> +  correctable errors seen.
> + * dev_breakdown_uncorrectable: Provides a breakdown of different type of
> +  uncorrectable errors seen.
> +
> +2.4.1 Rootport sysfs Attributes
> +
> +These attributes showup under only the rootports that are AER capable. These
> +indicate the number of error messages as "reported to" the rootport. Please 
> note
> +that the rootports also transmit (internally) the ERR_* messages for errors 
> seen
> +by the internal rootport PCI device, so these counters includes them and are
> +thus cumulative of all the error messages on the PCI hierarchy originating
> +at that root port.
> +
> + * rootport_total_cor_errs: number of ERR_COR messages reported to rootport.
> + * rootport_total_fatal_errs: number of ERR_FATAL messages reported to 
> rootport.
> + * rootport_total_nonfatal_errs: number of ERR_NONFATAL messages reporeted to
> + rootport.

These all belong in Documentation/ABI/ please.

thanks,

greg k-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 2/5] PCI/AER: Add sysfs stats for AER capable devices

[Greg Kroah-Hartman]

On Tue, May 22, 2018 at 03:28:02PM -0700, Rajat Jain wrote:
> Add the following AER sysfs stats to represent the counters for each
> kind of error as seen by the device:
> 
> dev_total_cor_errs
> dev_total_fatal_errs
> dev_total_nonfatal_errs

You need Documentation/ABI/ updates for new sysfs files please.

thanks,

greg k-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 4/5] acpi/processor: Fix the return value of acpi_processor_ids_walk()

[Rafael J. Wysocki]

On Wed, May 23, 2018 at 3:34 AM, Dou Liyang  wrote:
> At 05/22/2018 09:47 AM, Dou Liyang wrote:
>>
>>
>>
>> At 05/19/2018 11:06 PM, Thomas Gleixner wrote:
>>>
>>> On Tue, 20 Mar 2018, Dou Liyang wrote:
>>>
 ACPI driver should make sure all the processor IDs in their ACPI
 Namespace
 are unique for CPU hotplug. the driver performs a depth-first walk of
 the
 namespace tree and calls the acpi_processor_ids_walk().

 But, the acpi_processor_ids_walk() will return true if one processor is
 checked, that cause the walk break after walking pass the first
 processor.

 Repace the value with AE_OK which is the standard acpi_status value.

 Fixes 8c8cb30f49b8 ("acpi/processor: Implement DEVICE operator for
 processor enumeration")

 Signed-off-by: Dou Liyang 
 ---
   drivers/acpi/acpi_processor.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/acpi/acpi_processor.c
 b/drivers/acpi/acpi_processor.c
 index 449d86d39965..db5bdb59639c 100644
 --- a/drivers/acpi/acpi_processor.c
 +++ b/drivers/acpi/acpi_processor.c
 @@ -663,11 +663,11 @@ static acpi_status __init (acpi_handle handle,
   }
   processor_validated_ids_update(uid);
 -return true;
 +return AE_OK;
   err:
   acpi_handle_info(handle, "Invalid processor object\n");
 -return false;
 +return AE_OK;
>>>
>>>
>>> I'm not sure whether this is the right return value here. Rafael?
>>>
>
> +Cc Rafael's common used email address.
>
> I am sorry, I created the cc list using ./script/get_maintainers.pl ...
> and didn't check it.

No worries, I saw your messages, but thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 4/5] arm64: dts: sdm845: Add serial console support

[Rajendra Nayak]

On 03/30/2018 10:38 PM, Karthikeyan Ramasubramanian wrote:
> From: Rajendra Nayak 
> 
> Add the qup uart node and geni se instance needed to
> support the serial console on the MTP.
> 
> Signed-off-by: Rajendra Nayak 
> Signed-off-by: Karthikeyan Ramasubramanian 
> ---

Andy, is it possible to pull this one in for 4.18?
Sorry, I only realized we somehow missed this after looking at your pull 
request.

This is the only patch that prevents linux-next from booting up my sdm845 MTP
to a minimal console shell.

Thanks,
Rajendra

>  arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 41 
> +
>  arch/arm64/boot/dts/qcom/sdm845.dtsi| 39 +++
>  2 files changed, 80 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts 
> b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> index 979ab49..17b2fb0 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> @@ -12,4 +12,45 @@
>  / {
>   model = "Qualcomm Technologies, Inc. SDM845 MTP";
>   compatible = "qcom,sdm845-mtp";
> +
> + aliases {
> + serial0 = 
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> + {
> + geniqup@ac {
> + status = "okay";
> +
> + serial@a84000 {
> + status = "okay";
> + };
> + };
> +
> + pinctrl@340 {
> + qup-uart2-default {
> + pinconf_tx {
> + pins = "gpio4";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + pinconf_rx {
> + pins = "gpio5";
> + drive-strength = <2>;
> + bias-pull-up;
> + };
> + };
> +
> + qup-uart2-sleep {
> + pinconf {
> + pins = "gpio4", "gpio5";
> + bias-pull-down;
> + };
> + };
> + };
>  };
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 32f8561..71801b9 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -6,6 +6,7 @@
>   */
>  
>  #include 
> +#include 
>  
>  / {
>   interrupt-parent = <>;
> @@ -194,6 +195,20 @@
>   #gpio-cells = <2>;
>   interrupt-controller;
>   #interrupt-cells = <2>;
> +
> + qup_uart2_default: qup-uart2-default {
> + pinmux {
> + function = "qup9";
> + pins = "gpio4", "gpio5";
> + };
> + };
> +
> + qup_uart2_sleep: qup-uart2-sleep {
> + pinmux {
> + function = "gpio";
> + pins = "gpio4", "gpio5";
> + };
> + };
>   };
>  
>   timer@17c9 {
> @@ -272,5 +287,29 @@
>   #interrupt-cells = <4>;
>   cell-index = <0>;
>   };
> +
> + geniqup@ac {
> + compatible = "qcom,geni-se-qup";
> + reg = <0xac 0x6000>;
> + clock-names = "m-ahb", "s-ahb";
> + clocks = < GCC_QUPV3_WRAP_1_M_AHB_CLK>,
> +  < GCC_QUPV3_WRAP_1_S_AHB_CLK>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + status = "disabled";
> +
> + uart2: serial@a84000 {
> + compatible = "qcom,geni-debug-uart";
> + reg = <0xa84000 0x4000>;
> + clock-names = "se";
> + clocks = < GCC_QUPV3_WRAP1_S1_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <_uart2_default>;
> + pinctrl-1 = <_uart2_sleep>;
> + interrupts = ;
> + status = "disabled";
> + };
> + };
>   };
>  };
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html